BranchesTags

Repository files navigation

Contributing to just_audio

Thank you for your interest in contributing!

Contributors not only contribute code but also help by submitting issues, contributing to issue discussions and helping to answer questions on StackOverflow.

This document outlines the rules and procedures when contributing.

How we use GitHub

We use GitHub as a place and tool for contributors to work together on project development. That is, we use it to report bugs, suggest improvements, and contribute code and documentation to address those bugs or suggestions. It is not used as the place to ask for help (For that we use StackOverflow via the just-audio tag).

Reporting a bug

  1. Is it a bug? Check first that you're using the API correctly according to the documentation (README and API documentation). If the API crashes when used incorrectly, you should not report a bug.
  2. Is it a new bug? Search the GitHub issues page for bugs. If this bug has already been reported, you should not report a new bug.
  3. How can we reproduce it? Fork this repository and make the "minimal" changes necessary to the example to reproduce the bug. This step is unnecessary if you choose to fix the bug yourself, or if the example already exhibits the bug without modification. If the only change to the example necessary to reproduce the bug is the audio source URL, it will be sufficient to supply that URL without forking the repository, as long as you clarify in your bug report what we should do with that URL.
  4. Submit a report! With all of the information you have collected you can submit a bug report via the "New issue" page on GitHub. It is necessary to fill in all required information provided by the template in the same format as the template to avoid automatic closure of the issue.

Things to AVOID:

  • Do not share your whole app as the minimal reproduction project. This is not "minimal" and it makes it difficult to understand what's happening.
  • Do not use a bug report to ask a question. Use StackOverflow instead.
  • Do not submit a bug report if you are not using the APIs correctly according to the documentation.
  • Try to avoid posting a duplicate bug.
  • Do not ignore the formatting requirements and instructions within the issue template.

Suggesting an improvement

The GitHub "New issue" page provides 2 templates for suggesting improvements: Feature requests and Documentation requests. In both cases, make sure you search existing issues to prevent yourself from posting a duplicate, and ensure that you fill in all required sections in the issue temaplate keeping the original formatting to avoid automatic closure.

Making a pull request

Pull requests are used to contribute bug fixes, new features or documentation improvements. Before working on a pull request, an issue should exist that describes the feature or bug.

To create a pull request:

  1. Fork this repository
  2. Create a branch for your changes. Branch off the major branch if introducing a breaking change that is not backwards compatible, or instead off the minor branch if making a non-breaking change or bug fix.
  3. Make your changes, updating the documentation if you have changed any API's behaviour.
  4. If you are the first to contribute to the next version, increment the version number in pubspec.yaml according to the pub versioning philosophy.
  5. Add a description of your change to CHANGELOG.md (format: * DESCRIPTION OF YOUR CHANGE (@your-git-username)).
  6. Run flutter analyze to ensure your code meets the static analysis requirements.
  7. Run flutter test to ensure all unit tests continue to work (Please consider also contributing unit tests covering your new code).
  8. Create the pull request via GitHub's instructions.
  9. link that pull request with the original issue.

Best practices for a pull request:

  • Follow the style of existing code, paying attention to whitespace and formatting. (In Dart, we use dart format which may already be integrated into your IDE.)
  • Check your diffs prior to submission. Try to make your pull request diff reflect only the lines of code that needed to be changed to address the issue at hand. If your diff also changes other things, such as by making superficial changes to code formatting and layout, or checking in superfluous files such as your IDE or other config files, please remove them so that your diff focus on the essential. That helps keep the commit history clean and also makes your pull request easier to review.
  • Try not to introduce multiple unrelated changes in a single pull request. Create individual pull requests so that they can be evaluated and accepted independently.
  • Use meaningful commit messages so that your changes can be more easily browsed and referenced.

About

Audio Player

Contributing

Contributing
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Repository files navigation
Contributing to just_audio
Thank you for your interest in contributing!
Contributors not only contribute code but also help by submitting issues, contributing to issue discussions and helping to answer questions on StackOverflow.
This document outlines the rules and procedures when contributing.
How we use GitHub
We use GitHub as a place and tool for contributors to work together on project development. That is, we use it to report bugs, suggest improvements, and contribute code and documentation to address those bugs or suggestions. It is not used as the place to ask for help (For that we use StackOverflow via the just-audio tag).
Reporting a bug
  1. Is it a bug? Check first that you're using the API correctly according to the documentation (README and API documentation). If the API crashes when used incorrectly, you should not report a bug.
  2. Is it a new bug? Search the GitHub issues page for bugs. If this bug has already been reported, you should not report a new bug.
  3. How can we reproduce it? Fork this repository and make the "minimal" changes necessary to the example to reproduce the bug. This step is unnecessary if you choose to fix the bug yourself, or if the example already exhibits the bug without modification. If the only change to the example necessary to reproduce the bug is the audio source URL, it will be sufficient to supply that URL without forking the repository, as long as you clarify in your bug report what we should do with that URL.
  4. Submit a report! With all of the information you have collected you can submit a bug report via the "New issue" page on GitHub. It is necessary to fill in all required information provided by the template in the same format as the template to avoid automatic closure of the issue.
Things to AVOID:
  • Do not share your whole app as the minimal reproduction project. This is not "minimal" and it makes it difficult to understand what's happening.
  • Do not use a bug report to ask a question. Use StackOverflow instead.
  • Do not submit a bug report if you are not using the APIs correctly according to the documentation.
  • Try to avoid posting a duplicate bug.
  • Do not ignore the formatting requirements and instructions within the issue template.
Suggesting an improvement
The GitHub "New issue" page provides 2 templates for suggesting improvements: Feature requests and Documentation requests. In both cases, make sure you search existing issues to prevent yourself from posting a duplicate, and ensure that you fill in all required sections in the issue temaplate keeping the original formatting to avoid automatic closure.
Making a pull request
Pull requests are used to contribute bug fixes, new features or documentation improvements. Before working on a pull request, an issue should exist that describes the feature or bug.
To create a pull request:
  1. Fork this repository
  2. Create a branch for your changes. Branch off the major branch if introducing a breaking change that is not backwards compatible, or instead off the minor branch if making a non-breaking change or bug fix.
  3. Make your changes, updating the documentation if you have changed any API's behaviour.
  4. If you are the first to contribute to the next version, increment the version number in pubspec.yaml according to the pub versioning philosophy.
  5. Add a description of your change to CHANGELOG.md (format: * DESCRIPTION OF YOUR CHANGE (@your-git-username)).
  6. Run flutter analyze to ensure your code meets the static analysis requirements.
  7. Run flutter test to ensure all unit tests continue to work (Please consider also contributing unit tests covering your new code).
  8. Create the pull request via GitHub's instructions.
  9. link that pull request with the original issue.
Best practices for a pull request:
  • Follow the style of existing code, paying attention to whitespace and formatting. (In Dart, we use dart format which may already be integrated into your IDE.)
  • Check your diffs prior to submission. Try to make your pull request diff reflect only the lines of code that needed to be changed to address the issue at hand. If your diff also changes other things, such as by making superficial changes to code formatting and layout, or checking in superfluous files such as your IDE or other config files, please remove them so that your diff focus on the essential. That helps keep the commit history clean and also makes your pull request easier to review.
  • Try not to introduce multiple unrelated changes in a single pull request. Create individual pull requests so that they can be evaluated and accepted independently.
  • Use meaningful commit messages so that your changes can be more easily browsed and referenced.
About
Audio Player
Contributing
Contributing
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
Contributing to just_audio
Thank you for your interest in contributing!
Contributors not only contribute code but also help by submitting issues, contributing to issue discussions and helping to answer questions on StackOverflow.
This document outlines the rules and procedures when contributing.
How we use GitHub
We use GitHub as a place and tool for contributors to work together on project development. That is, we use it to report bugs, suggest improvements, and contribute code and documentation to address those bugs or suggestions. It is not used as the place to ask for help (For that we use StackOverflow via the just-audio tag).
Reporting a bug
  1. Is it a bug? Check first that you're using the API correctly according to the documentation (README and API documentation). If the API crashes when used incorrectly, you should not report a bug.
  2. Is it a new bug? Search the GitHub issues page for bugs. If this bug has already been reported, you should not report a new bug.
  3. How can we reproduce it? Fork this repository and make the "minimal" changes necessary to the example to reproduce the bug. This step is unnecessary if you choose to fix the bug yourself, or if the example already exhibits the bug without modification. If the only change to the example necessary to reproduce the bug is the audio source URL, it will be sufficient to supply that URL without forking the repository, as long as you clarify in your bug report what we should do with that URL.
  4. Submit a report! With all of the information you have collected you can submit a bug report via the "New issue" page on GitHub. It is necessary to fill in all required information provided by the template in the same format as the template to avoid automatic closure of the issue.
Things to AVOID:
  • Do not share your whole app as the minimal reproduction project. This is not "minimal" and it makes it difficult to understand what's happening.
  • Do not use a bug report to ask a question. Use StackOverflow instead.
  • Do not submit a bug report if you are not using the APIs correctly according to the documentation.
  • Try to avoid posting a duplicate bug.
  • Do not ignore the formatting requirements and instructions within the issue template.
Suggesting an improvement
The GitHub "New issue" page provides 2 templates for suggesting improvements: Feature requests and Documentation requests. In both cases, make sure you search existing issues to prevent yourself from posting a duplicate, and ensure that you fill in all required sections in the issue temaplate keeping the original formatting to avoid automatic closure.
Making a pull request
Pull requests are used to contribute bug fixes, new features or documentation improvements. Before working on a pull request, an issue should exist that describes the feature or bug.
To create a pull request:
  1. Fork this repository
  2. Create a branch for your changes. Branch off the major branch if introducing a breaking change that is not backwards compatible, or instead off the minor branch if making a non-breaking change or bug fix.
  3. Make your changes, updating the documentation if you have changed any API's behaviour.
  4. If you are the first to contribute to the next version, increment the version number in pubspec.yaml according to the pub versioning philosophy.
  5. Add a description of your change to CHANGELOG.md (format: * DESCRIPTION OF YOUR CHANGE (@your-git-username)).
  6. Run flutter analyze to ensure your code meets the static analysis requirements.
  7. Run flutter test to ensure all unit tests continue to work (Please consider also contributing unit tests covering your new code).
  8. Create the pull request via GitHub's instructions.
  9. link that pull request with the original issue.
Best practices for a pull request:
  • Follow the style of existing code, paying attention to whitespace and formatting. (In Dart, we use dart format which may already be integrated into your IDE.)
  • Check your diffs prior to submission. Try to make your pull request diff reflect only the lines of code that needed to be changed to address the issue at hand. If your diff also changes other things, such as by making superficial changes to code formatting and layout, or checking in superfluous files such as your IDE or other config files, please remove them so that your diff focus on the essential. That helps keep the commit history clean and also makes your pull request easier to review.
  • Try not to introduce multiple unrelated changes in a single pull request. Create individual pull requests so that they can be evaluated and accepted independently.
  • Use meaningful commit messages so that your changes can be more easily browsed and referenced.
About
Audio Player
Contributing
Contributing
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
Contributing to just_audio
Thank you for your interest in contributing!
Contributors not only contribute code but also help by submitting issues, contributing to issue discussions and helping to answer questions on StackOverflow.
This document outlines the rules and procedures when contributing.
How we use GitHub
We use GitHub as a place and tool for contributors to work together on project development. That is, we use it to report bugs, suggest improvements, and contribute code and documentation to address those bugs or suggestions. It is not used as the place to ask for help (For that we use StackOverflow via the just-audio tag).
Reporting a bug
  1. Is it a bug? Check first that you're using the API correctly according to the documentation (README and API documentation). If the API crashes when used incorrectly, you should not report a bug.
  2. Is it a new bug? Search the GitHub issues page for bugs. If this bug has already been reported, you should not report a new bug.
  3. How can we reproduce it? Fork this repository and make the "minimal" changes necessary to the example to reproduce the bug. This step is unnecessary if you choose to fix the bug yourself, or if the example already exhibits the bug without modification. If the only change to the example necessary to reproduce the bug is the audio source URL, it will be sufficient to supply that URL without forking the repository, as long as you clarify in your bug report what we should do with that URL.
  4. Submit a report! With all of the information you have collected you can submit a bug report via the "New issue" page on GitHub. It is necessary to fill in all required information provided by the template in the same format as the template to avoid automatic closure of the issue.
Things to AVOID:
  • Do not share your whole app as the minimal reproduction project. This is not "minimal" and it makes it difficult to understand what's happening.
  • Do not use a bug report to ask a question. Use StackOverflow instead.
  • Do not submit a bug report if you are not using the APIs correctly according to the documentation.
  • Try to avoid posting a duplicate bug.
  • Do not ignore the formatting requirements and instructions within the issue template.
Suggesting an improvement
The GitHub "New issue" page provides 2 templates for suggesting improvements: Feature requests and Documentation requests. In both cases, make sure you search existing issues to prevent yourself from posting a duplicate, and ensure that you fill in all required sections in the issue temaplate keeping the original formatting to avoid automatic closure.
Making a pull request
Pull requests are used to contribute bug fixes, new features or documentation improvements. Before working on a pull request, an issue should exist that describes the feature or bug.
To create a pull request:
  1. Fork this repository
  2. Create a branch for your changes. Branch off the major branch if introducing a breaking change that is not backwards compatible, or instead off the minor branch if making a non-breaking change or bug fix.
  3. Make your changes, updating the documentation if you have changed any API's behaviour.
  4. If you are the first to contribute to the next version, increment the version number in pubspec.yaml according to the pub versioning philosophy.
  5. Add a description of your change to CHANGELOG.md (format: * DESCRIPTION OF YOUR CHANGE (@your-git-username)).
  6. Run flutter analyze to ensure your code meets the static analysis requirements.
  7. Run flutter test to ensure all unit tests continue to work (Please consider also contributing unit tests covering your new code).
  8. Create the pull request via GitHub's instructions.
  9. link that pull request with the original issue.
Best practices for a pull request:
  • Follow the style of existing code, paying attention to whitespace and formatting. (In Dart, we use dart format which may already be integrated into your IDE.)
  • Check your diffs prior to submission. Try to make your pull request diff reflect only the lines of code that needed to be changed to address the issue at hand. If your diff also changes other things, such as by making superficial changes to code formatting and layout, or checking in superfluous files such as your IDE or other config files, please remove them so that your diff focus on the essential. That helps keep the commit history clean and also makes your pull request easier to review.
  • Try not to introduce multiple unrelated changes in a single pull request. Create individual pull requests so that they can be evaluated and accepted independently.
  • Use meaningful commit messages so that your changes can be more easily browsed and referenced.
About
Audio Player
Contributing
Contributing
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Repository files navigation
Contributing to just_audio
Thank you for your interest in contributing!
Contributors not only contribute code but also help by submitting issues, contributing to issue discussions and helping to answer questions on StackOverflow.
This document outlines the rules and procedures when contributing.
How we use GitHub
We use GitHub as a place and tool for contributors to work together on project development. That is, we use it to report bugs, suggest improvements, and contribute code and documentation to address those bugs or suggestions. It is not used as the place to ask for help (For that we use StackOverflow via the just-audio tag).
Reporting a bug
  1. Is it a bug? Check first that you're using the API correctly according to the documentation (README and API documentation). If the API crashes when used incorrectly, you should not report a bug.
  2. Is it a new bug? Search the GitHub issues page for bugs. If this bug has already been reported, you should not report a new bug.
  3. How can we reproduce it? Fork this repository and make the "minimal" changes necessary to the example to reproduce the bug. This step is unnecessary if you choose to fix the bug yourself, or if the example already exhibits the bug without modification. If the only change to the example necessary to reproduce the bug is the audio source URL, it will be sufficient to supply that URL without forking the repository, as long as you clarify in your bug report what we should do with that URL.
  4. Submit a report! With all of the information you have collected you can submit a bug report via the "New issue" page on GitHub. It is necessary to fill in all required information provided by the template in the same format as the template to avoid automatic closure of the issue.
Things to AVOID:
  • Do not share your whole app as the minimal reproduction project. This is not "minimal" and it makes it difficult to understand what's happening.
  • Do not use a bug report to ask a question. Use StackOverflow instead.
  • Do not submit a bug report if you are not using the APIs correctly according to the documentation.
  • Try to avoid posting a duplicate bug.
  • Do not ignore the formatting requirements and instructions within the issue template.
Suggesting an improvement
The GitHub "New issue" page provides 2 templates for suggesting improvements: Feature requests and Documentation requests. In both cases, make sure you search existing issues to prevent yourself from posting a duplicate, and ensure that you fill in all required sections in the issue temaplate keeping the original formatting to avoid automatic closure.
Making a pull request
Pull requests are used to contribute bug fixes, new features or documentation improvements. Before working on a pull request, an issue should exist that describes the feature or bug.
To create a pull request:
  1. Fork this repository
  2. Create a branch for your changes. Branch off the major branch if introducing a breaking change that is not backwards compatible, or instead off the minor branch if making a non-breaking change or bug fix.
  3. Make your changes, updating the documentation if you have changed any API's behaviour.
  4. If you are the first to contribute to the next version, increment the version number in pubspec.yaml according to the pub versioning philosophy.
  5. Add a description of your change to CHANGELOG.md (format: * DESCRIPTION OF YOUR CHANGE (@your-git-username)).
  6. Run flutter analyze to ensure your code meets the static analysis requirements.
  7. Run flutter test to ensure all unit tests continue to work (Please consider also contributing unit tests covering your new code).
  8. Create the pull request via GitHub's instructions.
  9. link that pull request with the original issue.
Best practices for a pull request:
  • Follow the style of existing code, paying attention to whitespace and formatting. (In Dart, we use dart format which may already be integrated into your IDE.)
  • Check your diffs prior to submission. Try to make your pull request diff reflect only the lines of code that needed to be changed to address the issue at hand. If your diff also changes other things, such as by making superficial changes to code formatting and layout, or checking in superfluous files such as your IDE or other config files, please remove them so that your diff focus on the essential. That helps keep the commit history clean and also makes your pull request easier to review.
  • Try not to introduce multiple unrelated changes in a single pull request. Create individual pull requests so that they can be evaluated and accepted independently.
  • Use meaningful commit messages so that your changes can be more easily browsed and referenced.
About
Audio Player
Contributing
Contributing
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
Contributing to just_audio
Thank you for your interest in contributing!
Contributors not only contribute code but also help by submitting issues, contributing to issue discussions and helping to answer questions on StackOverflow.
This document outlines the rules and procedures when contributing.
How we use GitHub
We use GitHub as a place and tool for contributors to work together on project development. That is, we use it to report bugs, suggest improvements, and contribute code and documentation to address those bugs or suggestions. It is not used as the place to ask for help (For that we use StackOverflow via the just-audio tag).
Reporting a bug
  1. Is it a bug? Check first that you're using the API correctly according to the documentation (README and API documentation). If the API crashes when used incorrectly, you should not report a bug.
  2. Is it a new bug? Search the GitHub issues page for bugs. If this bug has already been reported, you should not report a new bug.
  3. How can we reproduce it? Fork this repository and make the "minimal" changes necessary to the example to reproduce the bug. This step is unnecessary if you choose to fix the bug yourself, or if the example already exhibits the bug without modification. If the only change to the example necessary to reproduce the bug is the audio source URL, it will be sufficient to supply that URL without forking the repository, as long as you clarify in your bug report what we should do with that URL.
  4. Submit a report! With all of the information you have collected you can submit a bug report via the "New issue" page on GitHub. It is necessary to fill in all required information provided by the template in the same format as the template to avoid automatic closure of the issue.
Things to AVOID:
  • Do not share your whole app as the minimal reproduction project. This is not "minimal" and it makes it difficult to understand what's happening.
  • Do not use a bug report to ask a question. Use StackOverflow instead.
  • Do not submit a bug report if you are not using the APIs correctly according to the documentation.
  • Try to avoid posting a duplicate bug.
  • Do not ignore the formatting requirements and instructions within the issue template.
Suggesting an improvement
The GitHub "New issue" page provides 2 templates for suggesting improvements: Feature requests and Documentation requests. In both cases, make sure you search existing issues to prevent yourself from posting a duplicate, and ensure that you fill in all required sections in the issue temaplate keeping the original formatting to avoid automatic closure.
Making a pull request
Pull requests are used to contribute bug fixes, new features or documentation improvements. Before working on a pull request, an issue should exist that describes the feature or bug.
To create a pull request:
  1. Fork this repository
  2. Create a branch for your changes. Branch off the major branch if introducing a breaking change that is not backwards compatible, or instead off the minor branch if making a non-breaking change or bug fix.
  3. Make your changes, updating the documentation if you have changed any API's behaviour.
  4. If you are the first to contribute to the next version, increment the version number in pubspec.yaml according to the pub versioning philosophy.
  5. Add a description of your change to CHANGELOG.md (format: * DESCRIPTION OF YOUR CHANGE (@your-git-username)).
  6. Run flutter analyze to ensure your code meets the static analysis requirements.
  7. Run flutter test to ensure all unit tests continue to work (Please consider also contributing unit tests covering your new code).
  8. Create the pull request via GitHub's instructions.
  9. link that pull request with the original issue.
Best practices for a pull request:
  • Follow the style of existing code, paying attention to whitespace and formatting. (In Dart, we use dart format which may already be integrated into your IDE.)
  • Check your diffs prior to submission. Try to make your pull request diff reflect only the lines of code that needed to be changed to address the issue at hand. If your diff also changes other things, such as by making superficial changes to code formatting and layout, or checking in superfluous files such as your IDE or other config files, please remove them so that your diff focus on the essential. That helps keep the commit history clean and also makes your pull request easier to review.
  • Try not to introduce multiple unrelated changes in a single pull request. Create individual pull requests so that they can be evaluated and accepted independently.
  • Use meaningful commit messages so that your changes can be more easily browsed and referenced.
About
Audio Player
Contributing
Contributing
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
Contributing to just_audio
Thank you for your interest in contributing!
Contributors not only contribute code but also help by submitting issues, contributing to issue discussions and helping to answer questions on StackOverflow.
This document outlines the rules and procedures when contributing.
How we use GitHub
We use GitHub as a place and tool for contributors to work together on project development. That is, we use it to report bugs, suggest improvements, and contribute code and documentation to address those bugs or suggestions. It is not used as the place to ask for help (For that we use StackOverflow via the just-audio tag).
Reporting a bug
  1. Is it a bug? Check first that you're using the API correctly according to the documentation (README and API documentation). If the API crashes when used incorrectly, you should not report a bug.
  2. Is it a new bug? Search the GitHub issues page for bugs. If this bug has already been reported, you should not report a new bug.
  3. How can we reproduce it? Fork this repository and make the "minimal" changes necessary to the example to reproduce the bug. This step is unnecessary if you choose to fix the bug yourself, or if the example already exhibits the bug without modification. If the only change to the example necessary to reproduce the bug is the audio source URL, it will be sufficient to supply that URL without forking the repository, as long as you clarify in your bug report what we should do with that URL.
  4. Submit a report! With all of the information you have collected you can submit a bug report via the "New issue" page on GitHub. It is necessary to fill in all required information provided by the template in the same format as the template to avoid automatic closure of the issue.
Things to AVOID:
  • Do not share your whole app as the minimal reproduction project. This is not "minimal" and it makes it difficult to understand what's happening.
  • Do not use a bug report to ask a question. Use StackOverflow instead.
  • Do not submit a bug report if you are not using the APIs correctly according to the documentation.
  • Try to avoid posting a duplicate bug.
  • Do not ignore the formatting requirements and instructions within the issue template.
Suggesting an improvement
The GitHub "New issue" page provides 2 templates for suggesting improvements: Feature requests and Documentation requests. In both cases, make sure you search existing issues to prevent yourself from posting a duplicate, and ensure that you fill in all required sections in the issue temaplate keeping the original formatting to avoid automatic closure.
Making a pull request
Pull requests are used to contribute bug fixes, new features or documentation improvements. Before working on a pull request, an issue should exist that describes the feature or bug.
To create a pull request:
  1. Fork this repository
  2. Create a branch for your changes. Branch off the major branch if introducing a breaking change that is not backwards compatible, or instead off the minor branch if making a non-breaking change or bug fix.
  3. Make your changes, updating the documentation if you have changed any API's behaviour.
  4. If you are the first to contribute to the next version, increment the version number in pubspec.yaml according to the pub versioning philosophy.
  5. Add a description of your change to CHANGELOG.md (format: * DESCRIPTION OF YOUR CHANGE (@your-git-username)).
  6. Run flutter analyze to ensure your code meets the static analysis requirements.
  7. Run flutter test to ensure all unit tests continue to work (Please consider also contributing unit tests covering your new code).
  8. Create the pull request via GitHub's instructions.
  9. link that pull request with the original issue.
Best practices for a pull request:
  • Follow the style of existing code, paying attention to whitespace and formatting. (In Dart, we use dart format which may already be integrated into your IDE.)
  • Check your diffs prior to submission. Try to make your pull request diff reflect only the lines of code that needed to be changed to address the issue at hand. If your diff also changes other things, such as by making superficial changes to code formatting and layout, or checking in superfluous files such as your IDE or other config files, please remove them so that your diff focus on the essential. That helps keep the commit history clean and also makes your pull request easier to review.
  • Try not to introduce multiple unrelated changes in a single pull request. Create individual pull requests so that they can be evaluated and accepted independently.
  • Use meaningful commit messages so that your changes can be more easily browsed and referenced.
About
Audio Player
Contributing
Contributing
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Repository files navigation
Contributing to just_audio
Thank you for your interest in contributing!
Contributors not only contribute code but also help by submitting issues, contributing to issue discussions and helping to answer questions on StackOverflow.
This document outlines the rules and procedures when contributing.
How we use GitHub
We use GitHub as a place and tool for contributors to work together on project development. That is, we use it to report bugs, suggest improvements, and contribute code and documentation to address those bugs or suggestions. It is not used as the place to ask for help (For that we use StackOverflow via the just-audio tag).
Reporting a bug
  1. Is it a bug? Check first that you're using the API correctly according to the documentation (README and API documentation). If the API crashes when used incorrectly, you should not report a bug.
  2. Is it a new bug? Search the GitHub issues page for bugs. If this bug has already been reported, you should not report a new bug.
  3. How can we reproduce it? Fork this repository and make the "minimal" changes necessary to the example to reproduce the bug. This step is unnecessary if you choose to fix the bug yourself, or if the example already exhibits the bug without modification. If the only change to the example necessary to reproduce the bug is the audio source URL, it will be sufficient to supply that URL without forking the repository, as long as you clarify in your bug report what we should do with that URL.
  4. Submit a report! With all of the information you have collected you can submit a bug report via the "New issue" page on GitHub. It is necessary to fill in all required information provided by the template in the same format as the template to avoid automatic closure of the issue.
Things to AVOID:
  • Do not share your whole app as the minimal reproduction project. This is not "minimal" and it makes it difficult to understand what's happening.
  • Do not use a bug report to ask a question. Use StackOverflow instead.
  • Do not submit a bug report if you are not using the APIs correctly according to the documentation.
  • Try to avoid posting a duplicate bug.
  • Do not ignore the formatting requirements and instructions within the issue template.
Suggesting an improvement
The GitHub "New issue" page provides 2 templates for suggesting improvements: Feature requests and Documentation requests. In both cases, make sure you search existing issues to prevent yourself from posting a duplicate, and ensure that you fill in all required sections in the issue temaplate keeping the original formatting to avoid automatic closure.
Making a pull request
Pull requests are used to contribute bug fixes, new features or documentation improvements. Before working on a pull request, an issue should exist that describes the feature or bug.
To create a pull request:
  1. Fork this repository
  2. Create a branch for your changes. Branch off the major branch if introducing a breaking change that is not backwards compatible, or instead off the minor branch if making a non-breaking change or bug fix.
  3. Make your changes, updating the documentation if you have changed any API's behaviour.
  4. If you are the first to contribute to the next version, increment the version number in pubspec.yaml according to the pub versioning philosophy.
  5. Add a description of your change to CHANGELOG.md (format: * DESCRIPTION OF YOUR CHANGE (@your-git-username)).
  6. Run flutter analyze to ensure your code meets the static analysis requirements.
  7. Run flutter test to ensure all unit tests continue to work (Please consider also contributing unit tests covering your new code).
  8. Create the pull request via GitHub's instructions.
  9. link that pull request with the original issue.
Best practices for a pull request:
  • Follow the style of existing code, paying attention to whitespace and formatting. (In Dart, we use dart format which may already be integrated into your IDE.)
  • Check your diffs prior to submission. Try to make your pull request diff reflect only the lines of code that needed to be changed to address the issue at hand. If your diff also changes other things, such as by making superficial changes to code formatting and layout, or checking in superfluous files such as your IDE or other config files, please remove them so that your diff focus on the essential. That helps keep the commit history clean and also makes your pull request easier to review.
  • Try not to introduce multiple unrelated changes in a single pull request. Create individual pull requests so that they can be evaluated and accepted independently.
  • Use meaningful commit messages so that your changes can be more easily browsed and referenced.
About
Audio Player
Contributing
Contributing
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages