Finishing Touches

Do some final touch-ups with my README and ADDITIONS documents.
This commit is contained in:
OxygenCobalt 2020-12-20 07:52:54 -07:00
parent d4d40c97ad
commit 5deea0c11e
No known key found for this signature in database
GPG key ID: 37DBE3621FE9AD47
4 changed files with 17 additions and 13 deletions

View file

@ -14,10 +14,12 @@
## About
Auxio is a local music player for android that I primarily built for myself.
Auxio is a local music player for android designed to be the perfect music player for myself. It only has the features I need out of a music player, and nothing more.
It only has the features that I use out of a music player and nothing more, with a Spotify-Like UI/UX combined with elements from [Phonograph](https://github.com/kabouzeid/Phonograph) and [Music Player GO](https://github.com/enricocid/Music-Player-GO).
Its meant to be consistent and reliable, while still being customizable and extendable if one wants to add their own features that I (Personally) don't need.
Auxio itself is customizable and extendable however, allowing others to add features that I personally do not use.
The UI/UX is heavily derived from both Spotify and other FOSS Music Players such as [Music Player GO](https://github.com/enricocid/Music-Player-GO) and [Phonograph](https://github.com/kabouzeid/Phonograph),
albeit with a heavy emphasis on usability, consistency, and simplicity.
**Note:** Auxio is still early in development, meaning that some things may change as time passes.
@ -70,7 +72,7 @@ Its meant to be consistent and reliable, while still being customizable and exte
Auxio accepts most contributions as long as they follow the [Contribution Guidelines](/.github/CONTRIBUTING.md).
Feature additions and Major UI changes are less likely to be accepted. See [Accepted Additions](/info/ADDITIONS.md) for more information.
However, feature additions and Major UI changes are less likely to be accepted. See [Accepted Additions](/info/ADDITIONS.md) for more information.
## License

View file

@ -2,10 +2,10 @@
<vector xmlns:android="http://schemas.android.com/apk/res/android"
android:width="24dp"
android:height="24dp"
android:tint="?attr/colorPrimary"
android:viewportWidth="24"
android:viewportHeight="24"
android:tint="?attr/colorPrimary">
<path
android:fillColor="@android:color/white"
android:pathData="M6,21h12L18,7L6,7v14zM8,9h8v10L8,19L8,9zM15.5,4l-1,-1h-5l-1,1L5,4v2h14L19,4h-3.5z"/>
android:viewportHeight="24">
<path
android:fillColor="@android:color/white"
android:pathData="M6,21h12L18,7L6,7v14zM8,9h8v10L8,19L8,9zM15.5,4l-1,-1h-5l-1,1L5,4v2h14L19,4h-3.5z" />
</vector>

View file

@ -1,2 +1,2 @@
<?xml version="1.0" encoding="utf-8"?>
<full-backup-content/>
<full-backup-content />

View file

@ -8,17 +8,19 @@ All guidelines from the [Contribution Guidelines](../.github/CONTRIBUTING.md) st
## Bug Fixes, Optimizations, Library Updates, Formatting, etc.
These will likely be accepted/added as long as they do not cause too much harm to the app's architecture or UX.
These will likely be accepted as long as they do not cause too much harm to the app's architecture or UX.
## New Options/Customizations
These will be accepted/added if I see the value in the addition of those options and if they don't cause harm to the app's design. Most new options are fine as long as they dont degrade the UI/UX.
These will be looked at with more scrutiny, as certain customizations may cause harm to the apps UI/UX while still not providing alot of benefits as a whole.
Overall I tend to accept these however if I see the benefits of adding this UI/Behavior customization.
**Note:** I will be adding Black Mode/Custom Accents in the future. Read the [FAQ](FAQ.md) for more information.
## Feature Additions and UI Changes
These are far less likely to be accepted/added. As I said, I want to avoid Auxio from becoming overly bloated with features I do not use, and therefore **I will only accept features/UI changes that directly benefit my own usage.** If they do not, then I will reject/ignore them. This does not rule out certain additions, but I am generally less likely to accept these kinds of requests.
These are far less likely to be accepted/added. As I said, I want to avoid Auxio from becoming overly bloated with features I do not use, and therefore **I will only accept features/UI changes that directly benefit my own usage.** If they do not, then I will reject/ignore them. This does not rule out all additions of this kind, but I am generally less likely to accept these kinds of requests/PRs.
Feel free to fork Auxio to add your own features however.