Best regards,
Your Silverjuke-Team
Statistics: Posted by Service-Team — 18. Dec 08, 11:51
]]>
Ah, finally understood
I which case it makes sense to keep this as wanted behaviour in case an existing script did something similar. Personally I'd say keep the queue-related stuff all with the player object and not put this single function with the program object, but functionwise everything will be cleanly available so it really isn't that important.
Only maybe improve the new manual text "Returns the selection or the workspace or the display. If nothing is selected there, return all tracks in the display." to something like "Returns the selection in the workspace. If nothing is selected there, return the selection in the display. If nothing is selected there return all tracks in the display." The current description is a bit ambiguous I think.
And maybe add a reference to this fucntionality to for instance the Player.getUrlAtPos() entry? I think that is where you would look for it as a programmer (as I said: it's player related functionality
).Cheers,
SilverEagle
Statistics: Posted by SilverEagle — 18. Dec 08, 11:23
]]>
in the post above, when talking about the "display", this is equal to the "queue". If we would add a player.getSelection() function, this would be equal to program.getSelection(2).
The idea behind the current behaviour (return workspace/queue selection or all queued urls) is to simplyfy some functions. Eg. the internal "burn" dialog uses this approach, to get the seletion without worrying about where it comes from.
However, we understand that there are situations where these "smart selection returning" is not desired.
Maybe this clearifies some things.
Best regards,
Your Silverjuke-Team
Statistics: Posted by Service-Team — 18. Dec 08, 11:05
]]>
Unless I fully misunderstand the queue is identical to the 'display', and the queue is a property of the player, not the program. To me it sounds like getSelection(1) will return a program property, but getSelection(2) will return a player property.
I just tested something: there is also a third function!!! If there is also no selection in the playlist/queue, the complete playlist/queue is returned...
I was wondering why you did not want to create something like:
program.getSelection() -> returns selected lines from workspace
player.getSelection() (or getQueueSelection()) -> return selection from queue
And if you want to know the contents of the queue, a programmer can just use player.queueLength and getUrlAtPos().
I know all about compelling reasons for keeping an API unchanged, but I think the current behaviour could easily be called a bug and should preferably not be kept like it is...
Regards,
SilverEagle
Statistics: Posted by SilverEagle — 18. Dec 08, 10:37
]]>
Thank you very much for your report.
We have checked the issue:
In the next version of Silverjuke (2.73 or later), program.getSelection() will have an additional parameter to define which URLs to return.
See http://www.silverjuke.net/sdk/program-g ... ction.html for details.
Best regards
Your Silverjuke-Team
Statistics: Posted by Service-Team — 18. Dec 08, 09:48
]]>
Currently the program.getSelection() does two different things which sound similar but are definitely diffent, while the caller has no idea which function was performed. (One is returning the selection from the workspace, if there is no seelction it is returning the queue.)
Could you fix this somehow so it will become a clean API with two separate calls for the two functions? From both a designers & programmers viewpoint I'd even like to change the existing functionality cause I cannot image any existing script using this reliably, even with a lot of workaround thinking I did not get my single-touch detector in BlueTouch/RedTouch working for 100% of possible situations.
Regards,
SilverEagle
Statistics: Posted by SilverEagle — 18. Dec 08, 08:45
]]>