Add Enqueue button in "Always Ask" Share Menu

MD77MD commented 4 years ago

Checklist

[x] I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
[x] I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
[x] This issue contains only one feature request. I will open one issue for every feature I want to request.

Describe the feature you want

Until newPipe 0.20.2, while playing a video in background or pop-up mode, sharing another video from others apps to newPipe would enqueue them directly. However this is changing in the upcoming release because it was determined to be bad UX #4562. therefor I am raising this issue to discuss an alternative for it.

A direct quote from developer:

When sharing a video to NewPipe and a play button is pressed, replace the current queue instead of enqueueing. Enqueueing can still be achieved opening info and then enqueueing, but enqueueing directly was bad UX since the user would not see what happened.

Is your feature request related to a problem? Please describe it

These are my related conversations with the developer about this issue: https://github.com/TeamNewPipe/NewPipe/pull/4562#issuecomment-712496743, https://github.com/TeamNewPipe/NewPipe/pull/4562#issuecomment-719837705

To summarize: when a video is shared, enqueueing to pop-up or background mode was done directly, however Stypox suggested an alternative to direct enqueueing by shareing video to newPipe, then opening its details from menu, then long pressing enqueue button... however this was a tedious alternative as it would take too much time and effort to do so compared to old method, especially if multiple videos are to be enqueued.. (you can try enqueueing 5 video yourself to see the vast difference).

also when sharing to pop-up or background mode, users actually do not really want video details... they actually just wants the video to be enqueued... if the users indeed wanted video details they would have choosen the first option (video details). ..more so, it results in wasting data for loading the video details page for each video.

Additional context

The alternative for old enqueueing method should be as easy as the old method (enqueueing directly).. it sould avoid wasting to much time and data.

@opusforlife2 suggested when the share menu appears, long pressing on pop-up or background option would enqueue the video ... my suggestion isn't far away from his but more intuitive if that's the right word. Instead of long pressing, a ( + )"plus sign" or something similar is to be added next to both modes on the right.

The work done in #4425 "Replace specific enqueue options with one" could be used to inspire more alternatives.

How will you/everyone benefit from this feature?

Makes life a little bit easier... but seriously, try enqueueing 5 video yourself in both ways to see the vast difference.

opusforlife2 commented 4 years ago

We don't need anything so complicated. Just an additional "Enqueue" option in the "Always Ask" menu will be enough. It should only show when a stream is open.

Long pressing inside a menu seems like bad UX, anyway.

MD77MD commented 4 years ago

i did suggest that too

opusforlife2 commented 3 years ago

Your title should directly state what you want. Your feature request in one line. Not a description of the situation or what will happen in the future.

MD77MD commented 3 years ago

Your title should directly state what you want. Your feature request in one line. Not a description of the situation or what will happen in the future.

I had hard time describing this, because this problem is not there yet. and in order for newcomers to understand what I'm talking abou i had to build up from scratch .... i think next time I'm just gana pretend it's already there ... building the explanation for the issue was not worth the amount of time i spent.

opusforlife2 commented 3 years ago

You can freely explain in your own words in the issue body. The title though has to contain certain keywords so interested users will know they are opening the correct issue.

vkay94 commented 3 years ago

I think enqueuing is too specific for this dialog. The point of the dialog is to define a default action which should be run automatically while opening a link outside from NewPipe - that's why there is "Just once" and "Always" ;)

Enqueing like this is coupled to the situation that there's already NewPipe playing a stream, therefore this action wouldn't stand "for its own" like the others do (I hope you understand what I mean :'))

opusforlife2 commented 3 years ago

Good point. What if the "Always" button is greyed out if Enqueue is selected?

opusforlife2 commented 3 years ago

Or, or, when a user shares a link to Newpipe and another stream is open, we could show a dialogue saying "Stream already playing:

Play now, Enqueue, Cancel".

s1awek commented 3 years ago

Any updates on this?

MD77MD commented 3 years ago

So it seems you can do this with newer versions according to @Stypox, but the steps are awful [1]. First, change your NewPipe default from "Background player" to "Show info". Then, here is what you have to do for each video to be added:

Long press link

Click Open With NewPipe App

Long press Background

Compared to previous:

Long press link

Click Open With NewPipe App

I will continue to use the old version [2] until this is resolved.

#4562 (comment)

https://github.com/TeamNewPipe/NewPipe/releases/tag/v0.20.2

@89z better yet, you can instal the legacy version 20.2 of newpipe to handle shared links, and normal newpipe (or block adds version) for normal use. this way you can still enjoy the latest version with all its features.

this is what we have to do when no buddy cares to listen anymore 🙁

thinsoldier commented 3 years ago

@MD77MD how do you get 2 different versions of the same app installed at the same time?

MD77MD commented 3 years ago

@MD77MD how do you get 2 different versions of the same app installed at the same time?

actually new publicity is a bit different with a different signature... that's why android consider them aa two different apps because they effectively have two different signatures

this is the link to newpipe legacy version: (or ] can find it yourself from from the TeamNewpipe page;

https://github.com/TeamNewPipe/NewPipe-legacy/releases/tag/v0.20.2

P.S: only up to v0.20.2 still have enqueue, later versions dont lost this feature.

atmosfar commented 3 years ago

An unfortunate break in functionality from the earlier versions, hope a simple UX can return. The "official" flow described by @89z is far too convoluted for such an obvious task.

s1awek commented 3 years ago

I just don't get why issues about this functionality are being closed one by one without solving it?

s1awek commented 3 years ago

@s1awek Duplicate issues are not required to solve a single problem? A single issue needs to stay open regarding this.

So what issue is now active? Because so far all the issues I've been watching so far been closed.

Bruceforce commented 3 years ago

@s1awek Duplicate issues are not required to solve a single problem? A single issue needs to stay open regarding this.

So what issue is now active? Because so far all the issues I've been watching so far been closed.

This one here you just commented is still active.

MD77MD commented 3 years ago

the only thing we're good at here in newpipe is closing issues not solving them lol

s1awek commented 3 years ago

@MD77MD Just wondering if Google have some spies here just to destroy development process from inside ;)

chouhanyang commented 3 years ago

Hello,

I'm new to this project. However, my daily routine relies on the "enqueue" to background player heavily, and I actually never use NewPipe UI but sharing video streams from YouTube app instead. My use case looks like:

Open YouTube App.
Search my favorite talk shows and share to NewPipe background player.
Continue enqueue few shows since I'll listen to them while driving.

I'm not sure what is the policy of the core UI team. I just did a minimum fix since I REALLY needed to do this every single morning. :) My fix added "Enqueue background" option to the menu which means "enqueue to background player only" to avoid UI confusion:

device-2021-03-11-171859

You can find the release apk here: https://github.com/SavantOne/NewPipe/releases/tag/v0.20.11-patch

I'll probably patch once a while depending on the official NewPipe release. I cannot rely on old 0.20.2 forever since YouTube may change constantly as we all know. Let me know if you think I should send PR for this change and appreciate if someone from the core team can point me to the test process and/or review process.

s1awek commented 3 years ago

You are absolut star! Working lika a charm. Thank you very much :)

MD77MD commented 3 years ago

Hello,

I'm new to this project. However, my daily routine relies on the "enqueue" to background player heavily, and I actually never use NewPipe UI but sharing video streams from YouTube app instead. My use case looks like:

Open YouTube App.

Search my favorite talk shows and share to NewPipe background player.

Continue enqueue few shows since I'll listen to them while driving.

Since I'm not sure what is the policy of the core UI team. I just did a minimum fix since I REALLY needed to do this every single morning. :) My fix added "Enqueue background" option to the menu which means "enqueue to background player only" to avoid UI confusion:

You can find the release apk here: https://github.com/SavantOne/NewPipe/releases/tag/v0.20.11-patch

I'll probably patch once a while depending on the office NewPipe release. I cannot rely on old 0.20.2 forever since YouTube may change constantly as we all know. Let me know if you think I should send PR for this change and appreciate if someone from the core team can point me to the test process and/or review process.

@s1awek this what i was complaining about, how many issues where opened and closed for this simple fix, actually it was a function that was already there and removed by devs. and believe it or not, but i had much talk with dev about not removing it before they did... they told me no one needs it, however as you see people do need it.

anyway, i wish you would not accuse people just like that.

s1awek commented 3 years ago

@MD77MD

anyway, i wish you would not accuse people just like that.

You referring to "google spies" i mentioned earlier? I did not accuse anyone that was just a joke mate. Maybe a bad one though.

MD77MD commented 3 years ago

@MD77MD

anyway, i wish you would not accuse people just like that.

You referring to "google spies" i mentioned earlier? I did not accuse anyone that was just a joke mate. Maybe a bad one though.

I see, i guess i took it the wrong way... cheers...

btw thank you @chouhanyang for fix,

anther workaround i mentioned earlier, is to use newpipe legacy version 20.2 of newpipe to handle shared links, because best version still has that automatic enqueue function. that is until this fix is merged (god knows when😆)

thinsoldier commented 3 years ago

You can find the release apk here: https://github.com/SavantOne/NewPipe/releases/tag/v0.20.11-patch

Installed this 4x now (twice on 2 phones) and I don't see the enqueue option.

s1awek commented 3 years ago

@thinsoldier it's probably because now you have 2 NewPipe icons in share menu. Just pick a second one when sharing or you can just completely uninstall original app.

SameenAhnaf commented 3 years ago

I suggested a better solution in #5840.

Your wish: Add "Enqeue" option in "Always ask" share memu My wish: Include a separate option "Auto-enqueue videos shared from other apps if a media is playing" in settings.

Most expectedly, if a media has been already playing, I will enqueue the next video. If a user is never or rarely supposed to enqueue videos, he can disable or enable this option at any time.

There's no need to tripple tap (choose background player or popup again). Rather, double tap (1. Click Share, 2. Choose Newpipe) every time is enough.

There should be no "+" icon beside background player and popup as it may cause accidental touches. Plus, the UI should always stay clean and minimalist.

"Enqeue" option can't be directly included in "Preferred "Open" Action". There will have to be options like "Start playing on the background or enqeue" and "Start playing on popup or enqeue". That actually sounds pretty confusing. A separate option could easily solve the problems.

MD77MD commented 3 years ago

I suggested a better solution in #5840.

Your wish: Add "Enqeue" option in "Always ask" share memu My wish: Include a separate option "Auto-enqueue videos shared from other apps if a media is playing" in settings.

Most expectedly, if a media has been already playing, I will enqueue the next video. If a user is never or rarely supposed to enqueue videos, he can disable or enable this option at any time.

There's no need to tripple tap (choose background player or popup again). Rather, double tap (1. Click Share, 2. Choose Newpipe) every time is enough.

There should be no "+" icon beside background player and popup as it may cause accidental touches. Plus, the UI should always stay clean and minimalist.

"Enqeue" option can't be directly included in "Preferred "Open" Action". There will have to be options like "Start playing on the background or enqeue" and "Start playing on popup or enqeue". That actually sounds pretty confusing. A separate option could easily solve the problems.

to tell you the truth, both options are needed, as both have there own use case scenario. however i did not dear to ask for both. moreover the feature you are asking for was originally there and was oddly removed by one of the devs.

so i would suggest to keep both requests, perhaps one of them would go through.

SameenAhnaf commented 3 years ago

@MD77MD You are right, bro. Users should be given the flexibility to do so in both ways. However, "Enqeue background" option should be replaced by only "Enqeue" option. Anyone may ask for enqeuing videos on popup as well.

Stypox commented 3 years ago

@chouhanyang thank you for the contribution. Could you open a PR for that? I wasn't able to implement that properly before since there were crashes, could you open a PR so that we can discuss the implementation and merge it?

this what i was complaining about, how many issues where opened and closed for this simple fix, actually it was a function that was already there and removed by devs. and believe it or not, but i had much talk with dev about not removing it before they did... they told me no one needs it, however as you see people do need it.

@MD77MD Right from the beginning I think everyone agreed this could be added, but since there were problems with the implementation we (I) preferred not to provide a broken implementation, since a workaround is available. @chouhanyang did the right thing: he looked into the problem and found a way to solve it. Your tone instead is just counterproductive: complaining does not help, and one of the reasons I've not contributed much to NewPipe lately is because of such comments. If you think an issue is particularly important but we developers have a different idea, then try to help us anyway you can, e.g. describing the issue perfectly, providing various possible implementations and behaviours, analyzing pros and cons, explaining alternative solutions & showing why your solution is better, taking into consideration all of the consequences of a feature (like a more cluttered ui), ... (ideally learning Java and opening a PR, but that doesn't count). You did some of this, and you helped clear some doubts, but the bad comments just ruin everything. If, when a developer has the time to implement a feature, he finds a well-described one, where an agreement has already been reached between both parties and there is a clear solution that just needs implementing, it is far more likely that he will take it up. Instead, if he finds an issue where the proposed feature could benefit a user group but hurt another, where there is no pros-cons analysis and where there are hateful comments, probably he will just do something else (and maybe even feel frustrated).

An example of what I'm describing is https://github.com/TeamNewPipe/NewPipe/pull/4534#issuecomment-741700417 Before my comment there were many possible implementations available, but it wasn't clear which one would be the best. After my comment, instead:

three different alternatives have been proposed. Finding clever ideas is something everybody can do, if only they dedicate some time to it. I probably spent one hour thinking (just thinking!) about how to solve #4534 (fun fact: here are the sketches I drew)
the implementation details for each possible alternative were clear
pros and cons were analyzed and tradeoffs were clear
a clear consensous was reached

The only problem was that I had to write that comment myself: if it had been already there I would have probably taken up the issue much earlier and I wouldn't have wasted time on implementing a solution which at the end was discarded. Anyway, at least the discussion was constructive, there were no putting-off comments: if that were the case I would have probably just ignored them and done something else. It is really really frustrating to try to mediate between the needs and the opinions of many people, when nobody is willing to change their mind ever so slightly until the perfect solution is proposed by someone else. And sometimes there is not even a perfect solution.

chouhanyang commented 3 years ago

@Stypox Thanks for the pointer. A pull request is created and feel free to review/comment. In the mean time, I just setup an dev environment with physical device debugging, and it's pretty fun. Let me know if I could help a bit on other issues if you have in mind. And appreciate your contribution to this project.

Stypox commented 3 years ago

Please everyone go vote at https://github.com/TeamNewPipe/NewPipe/pull/5850#issuecomment-802736043 to choose the best solution :-D

triallax commented 3 years ago

It's probably too late for this, but why couldn't the behavior have been kept but with a toast when a video is enqueued? That would solve the issue, right? (Sorry if I missed something or this was suggested before, but I'm not interested in reading all the previous discussion.)

MD77MD commented 3 years ago

It's probably too late for this, but why couldn't the behavior have been kept but with a toast when a video is enqueued? That would solve the issue, right? (Sorry if I missed something or this was suggested before, but I'm not interested in reading all the previous discussion.)

exactly

MD77MD commented 3 years ago

It's probably too late for this, but why couldn't the behavior have been kept but with a toast when a video is enqueued? That would solve the issue, right? (Sorry if I missed something or this was suggested before, but I'm not interested in reading all the previous discussion.)

@mhmdanas is there any hope for this to be reimplemented?

triallax commented 3 years ago

@MD77MD well, #5850 is open, so I would say the answer is an obvious "yes." However, I have no idea when the PR will be merged.

Stypox commented 1 year ago

Simple proposal

Here is another simple and conservative proposal. We can just add the "Enqueue" option, but only enable it when the player is open and the queue is ready. If this is not the case, the share menu will be opened even if "Enqueue" is set as the preferred open action. The user will be able to choose there which action to perform.

This is consistent with the behavior that happens e.g. when "Popup player" is set as the preferred open action, but the user just shared a SoundCloud url for which there is no video: in that case the "Popup player" can't be opened (since there is no video), so the menu will show up.
This proposal implies a little more time spent on clicking actions for users that always use the same player and set "Enqueue" as the preferred open action. I am talking about users that would like the first shared url to automatically open a specific player and the following ones to automatically enqueue. Those users will have to manually choose the player they wish to open on the first shared url, but from then on the player will be open and so the "Enqueue" action will come into effect, so the urls shared afterwards are all enqueued without having to click actions. Therefore in the end I think it is a good tradeoff.
This solution is intuitive in my opinion, both because it is consistent with other similar behaviors, and because it is expected that when there is no player open the "Enqueue" can't be performed automatically and therefore further input from the user is needed.
This solution does not require adding any new button or settings option, making it more user friendly and accessible to more people.
It is basically the same as point 2.1 here, which has already won, except that is even simpler to implement since the "Always" button is not being hidden.