Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to set play option defaults #118

Closed
wants to merge 1 commit into from
Closed

Ability to set play option defaults #118

wants to merge 1 commit into from

Conversation

DavisNT
Copy link
Contributor

@DavisNT DavisNT commented Jul 12, 2015

New optional Boolean config options default_random, default_repeat, default_consume and default_single introduced.
If these option are set to true or false then corresponding playback options are set on Mopidy startup. This allows (geeky) users enable those options automatically on every Mopidy startup.

New config options default_random, default_repeat, default_consume and default_single introduced
@kingosticks
Copy link
Member

This feature belongs in Mopidy and is tracked at mopidy/mopidy#310.

@DavisNT
Copy link
Contributor Author

DavisNT commented Jul 12, 2015

I believe I will just work on my Mopidy-MusicBox-Webclient fork independently (because @kingosticks don't seem to be open to virtually any of my pull requests).
Looks like we have very different opinions on features and quality.

@kingosticks
Copy link
Member

The project mandate is a simple and easy to use client. Configurable
options generally go against this so we want to make sure they are
necessary. We also only want them if they will be useful for the majority
of people. All contributions are appreciated but some are just not aligned
with the project aims.

However, in this particular case, the feature belongs in Mopidy core and
not here. Please don't take it personally and please do send any bug fixes
back upstream to us here.
On 12 Jul 2015 17:40, "Dāvis Mošenkovs" notifications@github.com wrote:

I believe I will just work on my Mopidy-MusicBox-Webclient fork
independently (because you don't seem to be open to virtually any pull
requests).
Looks like we have very different opinions on features and quality.


Reply to this email directly or view it on GitHub
#118 (comment)
.

@DavisNT
Copy link
Contributor Author

DavisNT commented Jul 14, 2015

The Mopidy issue 310 is about preserving the state (this is a bit different feature). Does this feature belong here or in core is a good question, but I believe I wouldn't be the only user benefiting from this feature.

I am not taking anything personally (I hope you don't either), but I am respecting my (and your) time and I don't see that my attempts to contribute are productive here.

The worst (but not the only one) example is here: pimusicbox/mopidy-websettings#12 At first I was told that changes in startup script are required, but when they were completed (+ some testing done) I was informed that the feature is not welcome. Sorry to say, but this was really demotivating for me. Regarding importance of that feature I can agree that it is not the most important one, but I expect the feature not welcome as the very first comment, not as the last one (when the feature is code complete and tested). Afterwards the discussion shifted to globally writable /boot where it ended with my comment about possible solutions (left without response). So on both of these topics I have wasted several hours with no ROI (no changes in Pi MusicBox). Please correct me if I am wrong!

P.S. This is not the only one open-source project to which I have contributed, but, sad to say, contribution/collaboration productivity here was the worst.

@kingosticks
Copy link
Member

I agree it's a useful feature for Mopidy core and the activity on 310 is proof enough that it's popular but I really do think it belongs there rather than a random client.

Regarding pimusicbox/mopidy-websettings#12, I am sorry that your initial work won't be included, I can see that it's frustrating. Perhaps if I had looked more closely at it sooner than that wasted effort could have been avoided. I thought that some really good ideas come off the back of it and I intend to make use of what was discussed - hence the PR is still open and still relevant. I've been bogged down with various other things lately and not made the progress I wanted on the next Musicbox release which annoyingly gates a lot of the more interesting stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants