Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Request: %is_stop_after_current% (Read 8612 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Request: %is_stop_after_current%

Oh my god, they actually changed the stop after current behaviour so it selects the next track on stop! Amazing! Why was this not even advertised, it's great! In before shitstorm...


Great! Thank you, dear developers. Now, how about adding %is_stop_after_current%? We asked for it many times...
Ceterum censeo, there should be an "%is_stop_after_current%".

Request: %is_stop_after_current%

Reply #1

Oh my god, they actually changed the stop after current behaviour so it selects the next track on stop! Amazing! Why was this not even advertised, it's great! In before shitstorm...


Great! Thank you, dear developers. Now, how about adding %is_stop_after_current%? We asked for it many times...


Yes, pleaseeee add %is_stop_after_current%.  If you are operating foobar with a remote, there really is no way to tell if stop after current is active or not.

Request: %is_stop_after_current%

Reply #2
We asked for it many times...

And "we" have explained many times that title formatting is not suited for such information.

Besides, adding it as a checkbox within the toolbar or the status bar would be much more useful, because you could actually modify it.


Request: %is_stop_after_current%

Reply #4
Those fields are perfectly valid from an API point of view.

You might have noticed that they are not available in any context. That is because components have to call a special API function to format the currently playing title. They can even choose the level of playback-related information, ranging from basic playing/paused states, over dynamic track titles on live streams, to playback time and variable bitrate display. I assume you only mentioned %isplaying% and the like for the sake of the argument, and are not actually suggesting to remove those features, are you?

Now, the stop after current state is different. It is not a track property, not even of the currently playing track. Also note that when I commented on what title formatting is suited for, I am not merely refering to my personal opinion on what it should be capable of in general. I also have in mind the implications it would have. Implementation-wise, it is not a good idea to add such variables in a global fashion.

Even from a usability point of view, it does not make much sense. It is a setting, not just an information, and as such users would probably want to modify its state where it is displayed, instead of having to go somewhere else. So as already said a checkbox that is always visible would be better.

Request: %is_stop_after_current%

Reply #5
Now, the stop after current state is different. It is not a track property, not even of the currently playing track. Also note that when I commented on what title formatting is suited for, I am not merely refering to my personal opinion on what it should be capable of in general. I also have in mind the implications it would have. Implementation-wise, it is not a good idea to add such variables in a global fashion.

Even from a usability point of view, it does not make much sense. It is a setting, not just an information, and as such users would probably want to modify its state where it is displayed, instead of having to go somewhere else. So as already said a checkbox that is always visible would be better.

Would you say foo_cwb_hooks wasn't usable because it contradicted some "diploma thesis theory" design principles?
Reality as simple as that: If Peter would need a state indicating boolean variable for stop after current, we would already have this and no one would complain.
I still don't see the end of the world if we had cleanly designed get and set functions consistently for any function fb2k has.

Request: %is_stop_after_current%

Reply #6
The dilemma, as I see it:

At present, titleformatting (and its various bastard stepchildren) is the *only* way to render information in any number of components, third-party and otherwise.

Titleformatting is, according to the official point of view on the matter, not suitable for passing information on the state of the player (among other things). Whether you agree with this point of view or not, railing against it is a waste of time and energy at this point. And even on the global waste of time and energy that is the internet, there are probably more constructive paths to be taken.

I don't think anyone (official) is saying that it would be bad to have this information available to components in *some* form, just that titleformatting should not be the form that this takes. (Let's not get into the whole Visual Customization: Threat Or Menace? thing for the hundredth time, please.) So the question becomes, what form *should* it take?

I feel confident that this dilemma will be resolved sooner or later, by someone. (I also feel confident that there will be arguments about whether it was the right way to solve it, since this is still the Electric Time-Wasting Machine That Is The Internet.)

 

Request: %is_stop_after_current%

Reply #7
Would you say foo_cwb_hooks wasn't usable because it contradicted some "diploma thesis theory" design principles?
foo_cwb_hooks mainly violated the ability to dispatch change notifications only to affected tracks. It's easy to link %isplaying% - the update is sent to the previous and currently playing track. But it's not possible with %system_time% or %is_stop_after_current% - sending change notifications to all 30000 tracks in ML is stupid performance-wise, not sending them at all causes UI redraw issues, messes up autoplaylist generation, etc.
Reality as simple as that: If Peter would need a state indicating boolean variable for stop after current, we would already have this and no one would complain. I still don't see the end of the world if we had cleanly designed get and set functions consistently for any function fb2k has.
The SDK contains publicly available functions for retrieving and altering the stop-after-current state, as well as other options like playback-follows-cursor, cursor-follows-playback, always-on-top, etc. What kind of get/set interface and to what specific functions do you have in mind?

Generally, it would be better if people here restrained from talking about things they don't have a clue about. The world already has way too many misguided information spreading around and way too many inconsiderate requests, and those take way too much time and cause way too many useless debates and way too many harsh feelings.
Full-quoting makes you scroll past the same junk over and over.

Request: %is_stop_after_current%

Reply #8
Even from a usability point of view, it does not make much sense. It is a setting, not just an information, and as such users would probably want to modify its state where it is displayed, instead of having to go somewhere else. So as already said a checkbox that is always visible would be better.


I cannot argue about APIs, or what implications can anything have implementation-wise, or whatever. I know nothing about it.

But I think I can explain why it IMO nakes sense from a usability point of view.

I control my foobar mostly with global keyboard shorcuts: Play/Pause, Stop, Stop-after-current. The program just sits in the taskbar. I use stop-after-current a lot. Tracks I listen to are often long. So it is easy to forget if I did press stop-after-current or not. If the information was available as a title formatting variable, I could easily put it on the taskbar. Now I need to restore the  program window, go to the Playback menu and check if stop after current is checked. Two clicks in distant places of the screen to get information that I should be able to see without interrupting whatever I'm doing with my mouse and keyboard.

%is_stop_after_current% is one possible solution, if the systray icon changed depending on the stop-after-current status, I'd be happy enough. Just please let me see the status without moving my hand.
Ceterum censeo, there should be an "%is_stop_after_current%".

Request: %is_stop_after_current%

Reply #9
Quote
Just please let me see the status without moving my hand.

Request: %is_stop_after_current%

Reply #10
I don't think anyone (official) is saying that it would be bad to have this information available to components in *some* form, just that titleformatting should not be the form that this takes. (Let's not get into the whole Visual Customization: Threat Or Menace? thing for the hundredth time, please.) So the question becomes, what form *should* it take?


Right! And Frank didn't only say it is a bad feature he also gave ideas how that information could be displayed in an even more useful way - i also had an similar idea here. As you see, pawelq, there are so many ways to show that info - ways that are typical and well known in Windows. I will give you another example: Why should you ask for an replacement for %cwb_activelist_length%? Wouldn't the chance for a request  be better if you ask Peter if that info could be available beside the information about playlist selection length in the statusbar?

(By the way: As i have no knowledge about APIs and SDK i can't argue with that. But let me ask all the embittered ex_users of cwb_hooks from an user point of view: Did you really never remarked that some of foo_cwb_hooks functions wasn't able to be notified about changes in all cases??)

Request: %is_stop_after_current%

Reply #11
Quote
Just please let me see the status without moving my hand.



Yeah, a checkbox, a button that has an icon that changes depending on the status, a variable.  I really don't care how its done, just as long as its somehow visible in the main fb2k window without having to open any menus etc.

Request: %is_stop_after_current%

Reply #12
The HTPC concept (huge information display, based/fully dependent on variables) does not go well with "I declare a checkbox to be the appropriate way".

Quote
Did you really never remarked that some of foo_cwb_hooks functions wasn't able to be notified about changes in all cases??
Stanko, I'm still using cwb_hooks on my notebook. I use it for displaying playback order and system time. The system time cannot refresh if not playing. This is still a slight advantage over not displaying any of those.

Request: %is_stop_after_current%

Reply #13
@queller

I meant especially all the playlist-count/playlist-duration stuff - what could it mean that so far nobody seems to have remarked that although the people are crying for an replacement?

Request: %is_stop_after_current%

Reply #14
I really don't care how its done, just as long as its somehow visible in the main fb2k window without having to open any menus etc.


For me, the ideal way is to have it visible even without opening/restoring the main window. A variable that I could use to modify the application title on the taskbar is imo the best choice. The only alternative I can think of is modyfying the taskbar icon, which to me seems to be less flexible and more difficult to implement. All other possibilities (checkboxes, buttons, modyfing tray tooltips) I can imagine require additional action from the user, which I want to avoid. This is why I specifically requested a variable. But again, any way of showing it in a way that does not require action and is unobtrusive, is fine for me.
Ceterum censeo, there should be an "%is_stop_after_current%".

Request: %is_stop_after_current%

Reply #15
Yeah, a checkbox, a button that has an icon that changes depending on the status, a variable.  I really don't care how its done, just as long as its somehow visible in the main fb2k window without having to open any menus etc.
Noted, it will be added at some point.

To everyone else, please quit requesting nonsense title formatting functions like this, you're wasting your time. If you tell us what exactly it is you want to achieve, we're more likely to do something about it.
Microsoft Windows: We can't script here, this is bat country.

Request: %is_stop_after_current%

Reply #16
To everyone else, please quit requesting nonsense title formatting functions like this, you're wasting your time. If you tell us what exactly it is you want to achieve, we're more likely to do something about it.



OK. Is it too much to ask for it to be visible without accessing/restoring the program main window or taking any action whatsoever, on the taskbar or in the tray? That's exactly what I want to achieve.
Ceterum censeo, there should be an "%is_stop_after_current%".

Request: %is_stop_after_current%

Reply #17
Yeah, a checkbox, a button that has an icon that changes depending on the status, a variable.  I really don't care how its done, just as long as its somehow visible in the main fb2k window without having to open any menus etc.
Noted, it will be added at some point.

To everyone else, please quit requesting nonsense title formatting functions like this, you're wasting your time. If you tell us what exactly it is you want to achieve, we're more likely to do something about it.

In reality some nonsense stuff has turned out to be useful.
Most likely people may want to display Stop After Current indicators in Track Display panels. Fancy displaying. Which would be under ColumnsUI or the other UI. I'd say you'd waste your time putting this into default UI. Such people need variables, all the evil things cwb_hooks offered, you get the point.
As you basically disagree, I'd recommend you to better improve the gorgeous technical side of the player, like you did with the excellent converter interface.

Request: %is_stop_after_current%

Reply #18
Noted, it will be added at some point.


With some third-party components i have 20 toggable mainmenu items (including the hidden ones like "Replaygain: Set to album") - so i would really appreciate an universal solution for all that kind of items. Your notice just refer to "stop after current".

Request: %is_stop_after_current%

Reply #19
I'm really happy to hear that a stop after current indicator is planned, but would it be possible to 'upgrade' this feature request to state dependent buttons? e.g. a play/pause button as well? What about cursor follows playback/playback follows cursor?