Skip to main content
Topic: Playlist lock and autoplaylist APIs in 0.9.5.4 (Read 5060 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Playlist lock and autoplaylist APIs in 0.9.5.4

And for those not using Default UI there are no option to edit them [autoplaylists]? That's kinda silly, when they can be created independently of UI.
If your preferred user interface does not provide you any way to access standard functionality, you should blame nobody else but the author of that UI.
Overwrite 0.9.5.4 Default UI with 0.9.5.3's. Observe that autoplaylist editing funcationality is now not present in the Default UI playlist tabs. Are you saying autoplaylists are actually implemented in the Default UI or are you just trolling?
.

Playlist lock and autoplaylist APIs in 0.9.5.4

Reply #1
Observe that autoplaylist editing funcationality is now not present in the Default UI playlist tabs.
It is here. The command is called something like "Autoplaylist ..." or "Autoplaylist (Album List branch) ..."* both in the playlist manager element and in the playlist tabs. (Neither shows the lock status though...) It should still be possible to open the editing dialog through playlist_manager::playlist_lock_show_ui(). At least it does in my old playlist manager component. Strangely enough, I can't find a way to invoke the editor in Columns UI 0.3 beta 2 preview 11b.

*) I don't know what (new) API these UI elements use to retrieve the "(Album List branch)" part.

Playlist lock and autoplaylist APIs in 0.9.5.4

Reply #2
It is here. The command is called something like "Autoplaylist ..." or "Autoplaylist (Album List branch) ..."* both in the playlist manager element and in the playlist tabs. (Neither shows the lock status though...) It should still be possible to open the editing dialog through playlist_manager::playlist_lock_show_ui(). At least it does in my old playlist manager component. Strangely enough, I can't find a way to invoke the editor in Columns UI 0.3 beta 2 preview 11b.
foosion, I have tried repeatedly but there is no such command in 0.9.5.4 beta 1 in the playlist tabs when used with 0.9.5.3's Default UI. It comes back when you use 0.9.5.4's Default UI.

And, this API you refer to does nothing with autoplaylists in 0.9.5.3. So you are expecting me to have added menu items would have done nothing when clicked? There is no "playlist_lock_has_ui" so no method to disable the menu item. (BTW, even now I also have to consider users using versions older than 0.9.5.4 beta 1). I am sorry but your last sentence is about as trollish as the second post here.

Clearly there is some new API for checking whether it has such a dialog - in fact this entire thing seems to be done through some new API. I don't have a problem with that. But saying it is somehow my fault for not having implemented "standard" commands which are so standard the the Default UI didn't have them and would have had to be shown/clickable when they did nothing, which was essentially always, is completely wrong and out of order.
.

 

Playlist lock and autoplaylist APIs in 0.9.5.4

Reply #3
User interface components need updating to show autoplaylist editing dialogs, the old API was insufficient. The new API will be included with the next SDK update.

Edit: Actually, autoplaylist_client::show_ui() and playlist_lock::show_ui() work, but you need the new extensions to figure out whether this autoplaylist_client supports show_ui() or not as well as to get a label to show ("album list branch" etc).

Edit 2: As for beta 2, get_lock_name() only returns "Autoplaylist", I'll change it to return proper labels so you can pretty much fully implement editing with existing APIs.

Playlist lock and autoplaylist APIs in 0.9.5.4

Reply #4
Overwrite 0.9.5.4 Default UI with 0.9.5.3's. Observe that autoplaylist editing funcationality is now not present in the Default UI playlist tabs. Are you saying autoplaylists are actually implemented in the Default UI or are you just trolling?
I'm sorry if you found that sentence outrageous. I wasn't implying you should implement random API just in case they will work tomorrow. My reply was targetted mainly at the derogation tone of the OP, bitching along those well-known lines of preventing "unfaithful users" from accessing some functionality. This is what I had also craftily added to my post even before you responded, to avoid this kind of conversation.
ETA: Of course, I'm correcting mainly the overall bad reasoning here. It'll just need some time till the new functionality is added to third party components, this is just a beta preview after all.
Full-quoting makes you scroll past the same junk over and over.

Playlist lock and autoplaylist APIs in 0.9.5.4

Reply #5
And, this API you refer to does nothing with autoplaylists in 0.9.5.3. So you are expecting me to have added menu items would have done nothing when clicked? There is no "playlist_lock_has_ui" so no method to disable the menu item. (BTW, even now I also have to consider users using versions older than 0.9.5.4 beta 1). I am sorry but your last sentence is about as trollish as the second post here.
I am sorry, if that sentence sounded trollish to you. I was merely trying to convey my suprise that I couldn't find this command as I seemed to remember that you had already implemented that. Apparently my memory was wrong and I had confused this with my own foo_playlist_manager component where I had implemented this command to be on the safe side ("Show the command, when it may do something.") rather than following a conservative approach ("Show the command, when it is guaranteed to do something."). My reason was that there are components that implemented the playlist_lock::show_ui method (read-only playlists in foo_utils as well as foo_locktest).

Playlist lock and autoplaylist APIs in 0.9.5.4

Reply #6
[...]As for beta 2, get_lock_name() only returns "Autoplaylist", I'll change it to return proper labels so you can pretty much fully implement editing with existing APIs.
Thanks, but there wasn't a problem with there being new APIs. New APIs are usually good news  But I am not planning to implement this whilst I can't disable the command for pre-0.9.5.4 beta 1 users (i.e. with existing API). [edit] actually the autoplaylist methods in the SDK released a few weeks ago are surely enough to implement it for the autoplaylists, I don't know if there are any new methods for other locks though.

I'm sorry if you found that sentence outrageous. I wasn't implying you should implement random API just in case they will work tomorrow. My reply was targetted mainly at the derogation tone of the OP, bitching along those well-known lines of preventing "unfaithful users" from accessing some functionality.
Right but the point was you corrected "bad reasoning" with more "bad reasoning". You didn't need to blame anyone, especially if they haven't done anything wrong...

[...] my own foo_playlist_manager component where I had implemented this command to be on the safe side ("Show the command, when it may do something.") rather than following a conservative approach ("Show the command, when it is guaranteed to do something."). My reason was that there are components that implemented the playlist_lock::show_ui method (read-only playlists in foo_utils as well as foo_locktest).
Well sometimes I take cues from the Default UI
.

 
SimplePortal 1.0.0 RC1 © 2008-2019