foo_queuecontents enables the user to edit and view queue contents through an ui element. Both the Default User Interface (DUI) and Columns User Interface (CUI/uie) are supported. As a legacy option, queue contents can also be viewed and edited by a special queue playlist, which is updated automatically with queue contents.

Edit:If that is by design to make the component work so i must say that this is the craziest component ever: it destroys origin functionality of the queue to force some features the queue wasn't designed for.

I suppose this is the same bug, but if you rearrange items on the queue playlist the value of %queue_index% for the tracks on their original playlist are destroyed. Also, it would be nice if settings such as playlist name for the queue were accessable from a File> Preferences> Tools submenu.

Edit:If that is by design to make the component work so i must say that this is the craziest component ever: it destroys origin functionality of the queue to force some features the queue wasn't designed for.

It sure is possible. However, I think it outside the scope of this component (?). What do others think?

I believe that the queue is not saved by design (It's Not a Bug, It's a Feature!). The queue itself was discussed in different (long and boring) topic, and AFAIR core developer(s) stated there that the queue should remain plain and simple. I think that is the reason you had to do 'tricks' in your code responsible for changing queue items' order - because the queue is not intended to support such operations.

In other words, if you improve your component more and more, what will be the difference between using it, and using simple playlist with 'Remove After Playing' plugin (I remember that such thing existed somewhere)? You can already quickly send tracks to another playlist (eg. named 'Party' or 'Queue') using context-menu command.

I don't want to sound discouraging here, as I believe that great number of users don't agree with core developers and were looking for component such as yours.

My point is: if we have queue that looks like playlist, is managed like playlist, it would be nice if it saves automatically when foobar2000 is closed as other playlist do.If it will be done by foo_evilqueuesave, no problem for me.

My point is: if we have queue that looks like playlist, is managed like playlist... then why don't we just use playlist? Ohh, nevermind, I don't want to start flame war...

I bet that the very next request from some user would be 'not to flush whole playback queue' on playing track from outside the queue while it's being processed. Let alone implementing the 'simple' thing of saving queue's contents on exit.

I think that kerpondile made a very good foundation to create some kind of 'Advanced Queue' component, which would not base on core's (rather limited) functionality. Maybe it should be some kind of locked playlist which would disappear when it's empty (and reappear when someone adds track to it), and would automatically remove tracks from itself after playing them. Maybe for 'parties' it would have configurable options what users can and can't do with it (eg. allow/disallow to reorder, remove, etc.) And it would add command to context menu similar to the original queue. Maybe there could even be more than one queue!

Now, any 'improvement' to the original queue can lead to abuse of the core developer's intention, and I wouldn't be much surprised if it were banned for violating SDK license.

I'm posting to confirm the latest version fixes my previously stated issue with breaking %queue_index%, however I felt the need to point out that the Queue playlist doesnt honor any %queue_index% at all.

This component opens up some interesting uses for the playback queue but it needs to mature a bit. As for the whole "Foobar2000 best practices" debate, if you dont like the component dont use it. I'm always willing to explore new ways to manage my massive collection of music and nothing comes close to foobar on windows, mac, or linux.

Where did I say I don't like this component? I'm using it right now All I say is, the more this component is 'extending' core's queue possibilities, the closer it gets to normal (limited) playlist behavior. Whereas I'd like to see component that would start from being normal (locked) playlist and then be extended by new capabilities (like those that I mentioned in my previous post). I think that would be easier to program too, than hacking all core's queue restrictions. Anyways, I wish kerpondile all the best, because it is always good to see new potential in developers area

I am very aware that kerpondile surely put much effort in the development of this component. Also i am not interested to start a long and boring discussion about queues functionality.

But:

I hope i am allowed to mention that this component and all its praising is absurd. As mixcherry already said: All you can do with this component is possible without it - not in the sense of a workaround but in identical way if you use foo_utils. What is the long requested and needed functionality some people are talking about? Maybe you don't know foo_utils? Ok, now you know it! All the requests i read in this thread so far are realizable. Furthermore you don't have any restriction as you use a real playlist. You are not limited to 64 tracks and you also can choose playbackorder for your playlist. And if you like played track to be removed you can use foo_removeplayed

How far will the request concerning this new component go? mixcherry already bets that people will request to avoid flushback queue on starting another track manually. I bet that someone will request to start tracks inside of queue playlist manually or to avoid removal of played tracks. Such requests doesn't only mean ignorance of already existing funcionality but also confusion about the queue itself.

This component would only makes sense if and only if it wouldn't show the queue in a playlist but in a panel outside of the playlist view. So the queue would be recognizeable as queue.

AFAIK the only thing that makes a queue interesting is that it gets focus if it is filled with 1+ tracks and after being processed the last non-queue-track gets focus back again. AFAIK there is no way to give any playlist this feature of priority or does it?

Sometimes things come to your mind and you feel the need to put certain tunes into the stack, exactly at that time, right between your movements, even changing order of this temporary-set can be seen.. A PJ knows what I mean, but his live is hard.

I believe that the queue is not saved by design (It's Not a Bug, It's a Feature! ). The queue itself was discussed in different (long and boring) topic, and AFAIR core developer(s) stated there that the queue should remain plain and simple. I think that is the reason you had to do 'tricks' in your code responsible for changing queue items' order - because the queue is not intended to support such operations.

In other words, if you improve your component more and more, what will be the difference between using it, and using simple playlist with 'Remove After Playing' plugin (I remember that such thing existed somewhere)? You can already quickly send tracks to another playlist (eg. named 'Party' or 'Queue') using context-menu command.

I don't want to sound discouraging here, as I believe that great number of users don't agree with core developers and were looking for component such as yours.

Good luck

Yes, I understand your point and agree on some point. I believe users should be able to see and edit the queue and I think the only 'clean' way to do it (within the standard UI) is the playlist. I wanted to make this component a panel but I'm not that interested on foo_ui_columns etc. As far I know, it's not possible to create panels with current SDK.

QUOTE (q-stankovic @ Jul 29 2009, 17:42)

I am very aware that kerpondile surely put much effort in the development of this component. Also i am not interested to start a long and boring discussion about queues functionality.

But:

I hope i am allowed to mention that this component and all its praising is absurd. As mixcherry already said: All you can do with this component is possible without it - not in the sense of a workaround but in identical way if you use foo_utils. What is the long requested and needed functionality some people are talking about? Maybe you don't know foo_utils? Ok, now you know it! All the requests i read in this thread so far are realizable. Furthermore you don't have any restriction as you use a real playlist. You are not limited to 64 tracks and you also can choose playbackorder for your playlist. And if you like played track to be removed you can use foo_removeplayed

How far will the request concerning this new component go? mixcherry already bets that people will request to avoid flushback queue on starting another track manually. I bet that someone will request to start tracks inside of queue playlist manually or to avoid removal of played tracks. Such requests doesn't only mean ignorance of already existing funcionality but also confusion about the queue itself.

This component would only makes sense if and only if it wouldn't show the queue in a playlist but in a panel outside of the playlist view. So the queue would be recognizeable as queue.

I actually did not know about foo_utils. It seems to work very well. In an ideal situation my component would be a UI panel which could be placed where ever the user wants. Unfortunately this is not yet possible and the playlist seemed like the only way to it. However, after seeing how well foo_utils performs the same task, I'm wondering if my component is worth developing more.

QUOTE (durch @ Jul 30 2009, 01:14)

I agree it would be great if the queue would be a panel. Because I personally don't use the default UI, I'd prefer a Columns UI panel.

Own panel would give users well-proven Winamp-like queue functionality - a feature foobar2000 should have had right from the start IMO.

I'm personally not interested in Columns UI and I think there's already some plugins to do this in Columns UI.

I never really had the intention to add 'queue save' and other extra features because it's not very wise using the current SDK. SDK has quite crude api for queue (maybe intentionally?) and therefore making the job not feasible/rewarding. This plugin works in its basic job and adding new features on top of foobar queue is not wise. I'd have to take totally different approach to this (as some of you have suggested) problem if I'd like to bring more features.

I personally am going to change to foo_utils + remove played combination because it gives me more control and achieves basically the same thing (more cleanly at code level). When foobar SDK will support the standard panels I'm willing to take a look at the situation again.

my point wasn't only that foo_utils does the same job better but also that this job doesn't belong to queues functionality to override playback order during playback and to jump from playlist to playlist. And this functionality seemed to be forgotten or confused by many users - this confusion is forced by the fact that a playlist is used to mirror the content of the queue.

It would be a great pity for you after your effort to stop development before doing the last step. Sure, it is not possible to develop your component as ui element - but why don't you choose a free-floating pop-up window (callable by Mainmenu -> View->Playback Queue)? That would also be a clean solution and that is the way winamp users handle their queue since years without feeling the need to have the "Jump to File" window integrated into UI.