PDA

View Full Version : changing 'contextmenu' cli command to 'mixermenu'



bklaas
2009-05-11, 13:12
hi all, particularly Erland and perhaps Pippin-

I'd like to change the cli command called 'contextmenu', which was really not named correctly, to 'mixermenu'.

I'm currently in the process of expanding the Slim::Menu classes in 7.4 to allow for, in addition to trackinfo, an albuminfo, artistinfo, genreinfo, etc. This in essence will be add full SC-based context menu support, and as it follows a base class model, plugins will be able to add items to either all *info menus, or individual ones.

To be clear, I don't intend to use the cli term 'contextmenu' at all, but feel the existing command in that namespace is erroneously named.

cheers,
#!/ben

pippin
2009-05-11, 13:24
So what does this mean?
In the future there will be no more "contextmenu" command but a "mixermenu" command?
When will this change? Do I have to evaluate the version number and use "contextmenu" pre 7.4 and "mixermenu" post 7.4?
What happens if I use "contextmenu" on 7.4?

Is this really necessary?
When is the release date for 7.4? I expect to need at least two month until the next major iPeng release so I'd have to add a comment that iPeng will not work with 7.4 in the meantime.

pippin
2009-05-11, 13:47
Thinking a bit more about this I really, really find this a bad idea.

These kinds of specification changes cause additional testing, changes and add complexity. They will likely give several 1.000 users the choice to use an old server version or lose functionality for up to a few month.

And all that because the wording in the command sounds more appropriate???

I think this is a general issue:

Please. Learn. Stick. To. Specs.

Adding new things that do not work with all other software is fine but making arbitrary changes that kill existing functionality without real need is a bad habit quite common here.

Do you WANT to kill upwards compatibility? Why?

It's happened before a lot but that doesn't make it any better. It's unprofessional and will not leave a good impression among customers and will certainly make this platform less attractive.

peterw
2009-05-11, 13:58
I'm currently in the process of expanding the Slim::Menu classes in 7.4 to allow for, in addition to trackinfo, an albuminfo, artistinfo, genreinfo, etc. This in essence will be add full SC-based context menu support, and as it follows a base class model, plugins will be able to add items to either all *info menus, or individual ones.


Could you say more about "etc."? All the things you've listed sound like they're tied to the music library and its SC7 database. Will developers be able to define completely new "info" classes -- "serverinfo", "weatherinfo", "kitcheninfo", "tvinfo"?

How would this fit into real-world use? For instance, there's been talk about mapping the "+" button to some sort of context menu. If that were the case, would SC cycle through all the registered *info types, canning their providers to see who has anything to report or offer?

Thanks.

dean
2009-05-11, 14:50
why not make "mixermenu" an alias for "contextmenu" and update the
documentation to show one as supported but not recommended?


On May 11, 2009, at 1:12 PM, bklaas wrote:

>
> hi all, particularly Erland and perhaps Pippin-
>
> I'd like to change the cli command called 'contextmenu', which was
> really not named correctly, to 'mixermenu'.
>
> I'm currently in the process of expanding the Slim::Menu classes in
> 7.4
> to allow for, in addition to trackinfo, an albuminfo, artistinfo,
> genreinfo, etc. This in essence will be add full SC-based context menu
> support, and as it follows a base class model, plugins will be able to
> add items to either all *info menus, or individual ones.
>
> To be clear, I don't intend to use the cli term 'contextmenu' at all,
> but feel the existing command in that namespace is erroneously named.
>
> cheers,
> #!/ben
>
>
> --
> bklaas
>
> Logitech Developer:
> Squeezeplay/SqueezeOS/SqueezeboxController/SqueezeCenter
> Community Developer: Nokia770Skin
>
> http://www.last.fm/user/bklaas/
> 'KHAAAN!' (http://khaaan.com/)...'BUNNIES!'
> (http://home.pacbell.net/bettychu/2003allbreedbisris/BIS.html)
> ------------------------------------------------------------------------
> bklaas's Profile: http://forums.slimdevices.com/member.php?userid=58
> View this thread: http://forums.slimdevices.com/showthread.php?t=63268
>
>

pippin
2009-05-11, 15:05
why not make "mixermenu" an alias for "contextmenu" and update the
documentation to show one as supported but not recommended?



aka "Deprecated".
I think that would be the way to go.
BTW, I'm not sure there's a documentation for that command, isn't it?

bklaas
2009-05-11, 15:50
Thinking a bit more about this I really, really find this a bad idea.

These kinds of specification changes cause additional testing, changes and add complexity. They will likely give several 1.000 users the choice to use an old server version or lose functionality for up to a few month.

And all that because the wording in the command sounds more appropriate???

I think this is a general issue:

Please. Learn. Stick. To. Specs.

Adding new things that do not work with all other software is fine but making arbitrary changes that kill existing functionality without real need is a bad habit quite common here.

Do you WANT to kill upwards compatibility? Why?

It's happened before a lot but that doesn't make it any better. It's unprofessional and will not leave a good impression among customers and will certainly make this platform less attractive.

Pippin, no offense but you're jumping all over me for no reason.

It would be impossible for me to stick to specs because there ISN'T ONE.

Does *anyone* use the cli command called 'contextmenu'? My guess is no. If nobody uses it, we don't have a problem.

I added that cli command myself. It was named mistakenly. In my opinion, it has no utility outside of a couple calls within the core code. I'm trying to change that to avoid the confusion that you yourself pointed out elsewhere.

What I'm mandated to do right now is the "simple case", which is to use the trackinfo command to provide a context menu for track items. For squeezeplay, that's pretty much in place except for the "context menu-like" UI.

Now I'm trying to expand that to include playable non-track items, because I feel that is the critical spot in the UI, esp. Squeezeplay UI, where context menus have great utility.

That will include albuminfo, artistinfo, etc. (etc. = other items that are playable from the UI that aren't tracks). I will be adding them one at a time. Plugins will have the ability to add to any or all of these menus.

To answer peterw's question, I'm not really sure about 'kitcheninfo' and 'tvinfo' and all that...maybe it will scale to that level of abstraction but right now I'm concerning myself with music. Explore Slim::Menu for an idea of the base structure for these menus.

#!/ben

pippin
2009-05-11, 16:10
Pippin, no offense but you're jumping all over me for no reason.

Sorry, wasn't about you. More about the general development attitude at SD, which IMHO has to change


It would be impossible for me to stick to specs because there ISN'T ONE.

Bad enough


Does *anyone* use the cli command called 'contextmenu'? My guess is no. If nobody uses it, we don't have a problem.

I do. Erland adds stuff to it.


I added that cli command myself. It was named mistakenly. In my opinion, it has no utility outside of a couple calls within the core code. I'm trying to change that to avoid the confusion that you yourself pointed out elsewhere.

It's used by the Controller, isn't it? At least with Custom Browse


Sorry, maybe I was "jumping all over you" for the wrong occasion, but I generally feel something has to change about the way development in this ecosystem is handled.

You (and that's not "you, Ben", that's "you, SD") claim SC is an open source platform that can be used and expanded by anyone but it's still managed like an in-house hack in a lot of ways:

- For most of the functionality there is no mandatory spec
- Where there are specs they often are not followed
- Specs are being changed on short notice or on post-notice
- Changes are discussed behind closed doors and only being announced after they have been implemented, sometimes they are not being announced at all

I can give plenty of examples for this:
- The change from "Radio" to "Radios"
- The change in radio menu structure
- The change in Alarm functionality
- The SqueezePlay menu system
- you name it

While all of this is fine in a closed environment (although I would still call it a lack of engineering) it causes problems as soon as you want to expand the ecosystem to 3rd parties - and this is something SD claims to want to do

To explain this a bit:
When you do a new release for SC, typically there's no upfront planning on release dates, feature freezes, spec freezes etc.
If _I_ have to make a change in iPeng, if it's a trivial one it will take one month to market. If I'm lucky.
Your plugin authors may or may not be faster. Other 3rd party apps (like the ones for Win Mobile and Android) will have similar issues.

Now you can go out and say "this is not my problem, these are not my products" but that is not true. It's still your customers you piss off in the end if a lot of functionality stops to work. And an iPeng customer has spent $10 on iPeng but likely much more on SqueezeHardware. About whom will he be more pissed off, what do you think?

</rant>

Sorry, but I really feel that some of these things have to become more professional if you want to get rid of the "Sonos just works, Squeezebox has much more functionality but only works if you're lucky" comments out there in these other forums.

erland
2009-05-11, 18:11
Does *anyone* use the cli command called 'contextmenu'? My guess is no. If nobody uses it, we don't have a problem.

I'm using it in TrackStat, but it won't be a problem for me to update that to the next official release.

For iPeng's sake I would prefer a solution like dean suggests, where both commands is possible to use in the next release even if only one of them is recommended and documented.

Why do you want to change it to "mixermenu" ?
Aren't mixers supposed to be handled through the new context menu implementation ?
Will mixers still be something separate that's handled through some other mechanism ?
To me mixers just feels like a context menu item, but I might be missing something obvious.



That will include albuminfo, artistinfo, etc. (etc. = other items that are playable from the UI that aren't tracks). I will be adding them one at a time. Plugins will have the ability to add to any or all of these menus.

To answer peterw's question, I'm not really sure about 'kitcheninfo' and 'tvinfo' and all that...maybe it will scale to that level of abstraction but right now I'm concerning myself with music. Explore Slim::Menu for an idea of the base structure for these menus.

Remember that things like "Works", "Decades", "Composers", "Solists", "Moods", "Singles" are still related to music even though they aren't currently supported by the SqueezeCenter Slim::Schema::* database objects. I mentioned "Composers" since a composer might need different context menu items than an artist.

As I've understood the new database schema planned for 8.0 the idea is that you should be able to represent things like these and then it feels like a good idea that you also can have a context menu on them. It would be a bad idea to change the name now if you need to change it again to handle the new database schema.

I have to say that it feels a bit hard coded to have a solution that requires you to add a new CLI command every time a new type of object requires a context menu. It will probably also be a mess for third party applications like iPeng, since it results in that it needs to add support for new CLI commands every time you decide that a new object type should have a context menu. To make it even worse it requires iPeng to be synchronized with SqueezeCenter releases since a command might not be supported in all SqueezeCenter versions.

The excellent ContextMenu plugin which peterw has developed already have a very flexible context menu with an API that works for all kinds of menu objects not just the objects in Slim::Schema::*.

If you don't want to do a callback based API like the one implemented in ContextMenu, it would at least be a good idea to have a solution where it's possible to register new menu object types. This way third party plugins can add context menus to their menu hierarchies which might not always represent Slim::Schema::* objects. In this scenario it doesn't feel good to have hard coded CLI commands like "artistmenu", it feels a lot better to have a generic command like "contextmenu" where you as a parameter specify the object type and object identifier the menu is launched for.

If I remember correctly the documentation included with the ContextMenu plugin by peterw contains a pretty good description of its API if you like to steal some ideas. Peter has done some excellent work with the thoughts behind this API, so please at least take a look at it.

<rant>
This is not a personal rant against you Ben, the whole development team could learn from it.

I really wish you guys would take a deeper look at what third party plugins provide to steal some ideas from them. I'm not talking about copying the code, I just wish you at least took a look at the functionality and API's and took some inspiration from it. After all that's one of the reasons why it's a good idea to keep this software open source with an active third party developer community, isn't it ?

I've always felt developing third party plugins is a way to try out new ideas to make it easier to develop similar functionality a future SqueezeCenter release if users like it. However, it does feel like a bit wasted time if you don't take a deeper look at them. I understand that it takes time to analyze the details of the code, but at least spend some time asking the third party developer that has done similar things earlier to get the main principles, this way you don't have to repeat the mistakes already made during third party development.

I apologize in advance if someone gets hurt by these statements, but this is the way it feels like from my point of view.
</rant>

bklaas
2009-05-11, 21:37
First, apologies I spoke much stronger than I should have in my previous post. I didn't mean to seem that short-fused. In my defense, I just spent the workday listening to a new roof being installed on my (hail-damaged) house. A repetitive nail gun sound in the background for 8 hours while trying to code makes for a frustrated mind.

Back to my original question, I'll keep 'contextmenu' around since it sounds like it's being directly called by 3rd party plugins. I'm going to change the name of the command to mixermenu but make contextmenu alias to it per Dean's suggestion. Change your code as you see fit, but either will work going forward.

There are some really solid points that Erland and Pippin brought up regarding our interaction with the 3rd party development community. Honestly, I have no issue, none, with what's being said. However, I don't have a solution in the short term. We are operating on insanely tight timelines. We do not have time or resources to spend developing the type of processes that will result in a truly satisfactory 3rd party development environment. The Squeezeplay sw team, primarily three people, is tasked with not only developing and maintaining this new platform, but to communicate with an SC (and an SN) that's delivering diverse content from both core and 3rd party plugins. AND, we're hoping to build a 3rd party Lua applet development community that is currently nearly non-existent.

Don't get me wrong, I love working on this stuff. The reason I'm working at this job is because I was a member of the 3rd party development community. But talk of mandatory specs and involved outside consulting on design...I just don't see how it's going to happen right now. The engineering group is getting design direction not just right before we implement it, but literally _while_ we're implementing it. Where is outside consultation going to fit into that model?

Do take what I say in context--Dean or someone else internally may (and probably does) feel very differently than what I'm saying here. I'd welcome their thoughts on this thread.

I hope you respect that I'm not trying to be pessimistic but realistic. I don't think the documentation and direction we're delivering for 3rd party developers is reasonable, but it would be even less reasonable to be promising what can't be delivered.

#!/ben

mherger
2009-05-11, 23:21
Pippin,

quite a few very valid points, though with a bit of a bitter tone. But
then... hold on...

> - Changes are discussed behind closed doors and only being announced
> after they have been implemented, sometimes they are not being announced
> at all

Isn't the beginning of this thread exactly the opposite? Ben wanted to
discuss a change with you (the community) and now you're shooting him for
doing what you're asking for? That's not very encouraging...

As I said - there's a lot of good feedback in your mail. You should
probably start a new discussion in a calm, objective tone, without all the
bitterness which can come up when upset. There are clearly things we can
improve, but it needs an effort on both sides.

Michael

pippin
2009-05-12, 00:20
First, apologies I spoke much stronger than I should have in my previous post. I didn't mean to seem that short-fused.

Same here. Sorry for that.


We are operating on insanely tight timelines. We do not have time or resources to spend developing the type of processes that will result in a truly satisfactory 3rd party development environment.


> - Changes are discussed behind closed doors and only being announced
> after they have been implemented, sometimes they are not being announced
> at all
Isn't the beginning of this thread exactly the opposite? Ben wanted to
discuss a change with you (the community) and now you're shooting him for
doing what you're asking for? That's not very encouraging...

OK, again, sorry for the bitter tone.
I definitely didn't want to shoot at ANYBODY, definitely not Ben (I wrote so).

I just wanted to point to an issue. I had the feeling it's not being taken seriously. I did not mean to say anybody is not taking the community seriously, I have had a tremendous amount of support from you guys, also including early heads up to upcoming issues from both of you but also others including Dean, Andy, Richard and others.

My point is not directed at anybody: You are selling hardware based on this 3rd party community. It may not be the majority, but I can tell from the feedback I'm getting that a significant part of the customers iPeng is having are selecting Squeezebox hardware over other systems because of 3rd party content. Not only iPeng itself but also things like CustomBrowse or other plugins that add functionality other systems simply don't have.

As I said before, you are pissing these customers off if some of that stops working. I tend to be quick in using strong voice but I will also calm down fast and sit down and fix things. This way I did succeed in getting around a lot of these things. But it's not guaranteed. I do have a very different change cycle than you guys and if you include the community as a whole your 3rd party developers do so, too.

I know following specs and developing them before implementation feels like added bureaucracy but I can assure you that I have the experience to tell you: It's not. It makes your life easier. Really.
I'm developing iPeng on my own, too, and _I_ do it. Not for everything and not always detailed but I do write down what I want to do and I did file several bugs on proposals how to improve things WRT these menus (for example) here, some of them long back.
While I do usually get a lot of feedback, I never got formal one, as in: "hey, let's think about that spec."

And I'm not saying this just out of bitterness. I have just implemented the SqueezePlay menu system a few months back and all I can say is that the protocol is very new (the first product using it just launched a year ago or so) but it's seriously messed up. Honestly. It has a nice and clean spec on your WiKi and if you implement that you will see it won't work like that because it's not implemented like that. The thing that's implemented is an ugly protocol full of implementation details that don't follow the original spec and add all kinds of side-effects.
And I'm prepared to bet serious amounts that a lot of the issues people complain about on the Duet forum every day are rooted in just these kinds of things.



As I said - there's a lot of good feedback in your mail. You should
probably start a new discussion in a calm, objective tone, without all the
bitterness which can come up when upset. There are clearly things we can
improve, but it needs an effort on both sides.


You know, the sad thing is that this really isn't the first time I'm writing this. The first time I remember is more than a year back when I found out part of the functionality in the iPeng skin suddenly stopped working and I had no idea as to why.

I'm really willing to do my share of effort (writing all this being part of it) and actually it's not that long ago that I files a number of very long bugs with the intention to do just that but I need a discussion to do so, can't do it on my own.

bklaas
2009-05-15, 21:30
Sorry, I've been meaning to post to this thread for the past few days.

'contextmenu' is staying around, and will be used as a wrapper command for all context menus (and there was much rejoicing).

the existing 'contextmenu' cli command (originally meant to produce an interim menu for when a user had more than one mixer installed) can be called in exactly the same manner and will yield exactly the same results. Alternatively, that command can now be called with 'mixermenu' instaed.

extending it, using the menu:xxx flag will allow for the command to deliver different information. For example,
<playerid> contextmenu 0 200 menu:track track_id:<track_id>
will then call the 'trackinfo' command and deliver a context menu for a track (aka the trackinfo menu)

there is currently support for menu:(track|album|artist|genre|year)

these all make calls to Slim::Menu::*Info to yield object-specific context menus. SC Plugins can add items to any or all of these (I've already done it for MIP on albums and artists, as well as sending Michael a patch for Biography and AlbumReview plugins).

the contextmenu cli callback is implemented in
Slim::Control::Queries::contextMenuQuery()

I will update the cli command docs next week with details. A bug is open to track the documentation so I don't ignore that
http://bugs.slimdevices.com/show_bug.cgi?id=12074

cheers,
#!/ben

dean
2009-05-15, 21:59
A nice solution, Ben.

erland
2009-05-16, 00:10
extending it, using the menu:xxx flag will allow for the command to deliver different information. For example,
<playerid> contextmenu 0 200 menu:track track_id:<track_id>
will then call the 'trackinfo' command and deliver a context menu for a track (aka the trackinfo menu)

there is currently support for menu:(track|album|artist|genre|year)

Looking good Ben.

If possible, it would be nice if "playlist" also was supported on the context menu. This would make it possible to have options like "Play playlist in order" or "Play playlist in random order" or "Edit playlist" when we like to support that.

Another thing that might be good is to have "menu:remotetrack" since we might want to have different context menus on a locally stored music file and an internet radio station.

Would it be possible to let plugins be able to register their own "menu" values and connect them with a callback or CLI command ?
This way plugins would be able to use the contextmenu command instead of implementing their own context menu handling ?

Maybe it would be enough if the handling in Slim::Queries::contextMenuQuery was changed so instead of hardcoding the different "menu" values it would check if there is a CLI command named "xxxinfo items" registered where xxx is the value of the "menu" parameter ?
This way you don't have to implement any extra registration code since it's already in place through the normal CLI command registration.

Philip Meyer
2009-05-16, 00:37
>If possible, it would be nice if "playlist" also was supported on the
>context menu.
And I imagine a context menu on a favorite would be amis (to provide a shortcut to play, add, delete favorite and also navigate into the favorite).

pippin
2009-05-16, 02:03
Ben,

this sounds cool.
Do I get it correctly that this is what will be used for the context menu feature in SqueezePlay?

peterw
2009-05-17, 11:33
extending it, using the menu:xxx flag will allow for the command to deliver different information. For example,
<playerid> contextmenu 0 200 menu:track track_id:<track_id>
will then call the 'trackinfo' command and deliver a context menu for a track (aka the trackinfo menu)

there is currently support for menu:(track|album|artist|genre|year)

...
the contextmenu cli callback is implemented in
Slim::Control::Queries::contextMenuQuery()


My PlayLog plugin supports context menus on VFD-based players via my ContextMenu plugin. PlayLog needs to offer a "Log this track" option if a context menu is invoked on a player that is playing a track that has not already been logged by PlayLog (regardless of what the user is looking at).

To do that with your model, it sounds like PlayLog would need to
1) register itself as a context menu provider for (track|album|artist|genre|year), so that it would always have a chance at offering "Log this track"
and
2) use contextMenuQuery() to register a callback so that it would only suggest "Log this track" in the appropriate circumstances.

Is that right?

bklaas
2009-05-18, 06:52
Looking good Ben.

If possible, it would be nice if "playlist" also was supported on the context menu. This would make it possible to have options like "Play playlist in order" or "Play playlist in random order" or "Edit playlist" when we like to support that.

Another thing that might be good is to have "menu:remotetrack" since we might want to have different context menus on a locally stored music file and an internet radio station.

Would it be possible to let plugins be able to register their own "menu" values and connect them with a callback or CLI command ?
This way plugins would be able to use the contextmenu command instead of implementing their own context menu handling ?

Maybe it would be enough if the handling in Slim::Queries::contextMenuQuery was changed so instead of hardcoding the different "menu" values it would check if there is a CLI command named "xxxinfo items" registered where xxx is the value of the "menu" parameter ?
This way you don't have to implement any extra registration code since it's already in place through the normal CLI command registration.

All good points, Erland.

PlaylistInfo I'll try to add today.

RemoteTrack I'm not sure is necessary as TrackInfo already has code to handle remote vs. local menus. I'm open to debate on that one, but I probably won't be the person to implement the split.

Lastly, I like your approach to adding a check for "xxxinfo items" in contextMenuQuery. Will try to get that in today as well.

I'll keep you posted.

cheers,
#!/ben

pippin
2009-05-18, 07:34
RemoteTrack I'm not sure is necessary as TrackInfo already has code to handle remote vs. local menus. I'm open to debate on that one, but I probably won't be the person to implement the split.


I'm not sure I understand what you mean on that one.
Could you elaborate?
Can I use TrackInfo for a remote track, i.e. any URL?

bklaas
2009-05-18, 07:39
I'm not sure I understand what you mean on that one.
Could you elaborate?
Can I use TrackInfo for a remote track, i.e. any URL?

That's correct, the TrackInfo is available for remote (XMLBrowse) tracks as well as local SC tracks.

bklaas
2009-05-18, 07:51
My PlayLog plugin supports context menus on VFD-based players via my ContextMenu plugin. PlayLog needs to offer a "Log this track" option if a context menu is invoked on a player that is playing a track that has not already been logged by PlayLog (regardless of what the user is looking at).

To do that with your model, it sounds like PlayLog would need to
1) register itself as a context menu provider for (track|album|artist|genre|year), so that it would always have a chance at offering "Log this track"
and
2) use contextMenuQuery() to register a callback so that it would only suggest "Log this track" in the appropriate circumstances.

Is that right?

1) Yes, that's correct
2) in addition to the registerInfoProvider() method that all of the Slim::Menu::*Info classes have, there is also a deregisterInfoProvider() method to remove an item from a CM. If you want your plugin to dynamically add/delete from a CM, that's the route you want to go.

pippin
2009-05-18, 07:55
That's correct, the TrackInfo is available for remote (XMLBrowse) tracks as well as local SC tracks.

OK, one more thing: does it (or will it) also work on XMLBrowser playlists?

peterw
2009-05-18, 10:03
2) in addition to the registerInfoProvider() method that all of the Slim::Menu::*Info classes have, there is also a deregisterInfoProvider() method to remove an item from a CM. If you want your plugin to dynamically add/delete from a CM, that's the route you want to go.

You're saying I would do that instead of using a callback mechanism??? So each time a loggable track starts, I'd register for every info type, and when a user logged info about the track, I'd then de-register for every info type?

Can I do this on a per-player basis? PlayLog logs info associated with a given time and player. Just because something playing throughout the synced house was logged by Adam's player doesn't mean it shouldn't be logged by Eve's player.

Similarly, my new amp control plugin should provide a "Select amp source" menu only for players attached to controlled amps. How would I register an amp control CM to only be available on certain players?

If someone requests a menu while looking at an INPUT.List handled by one of my plugins, how would SC know what CM to show? It sounds like your context menus are only available from menus where the current item is obviously associated with a known info type (e.g. trackinfo).

bklaas
2009-05-18, 10:48
All good points, Erland.

PlaylistInfo I'll try to add today.

RemoteTrack I'm not sure is necessary as TrackInfo already has code to handle remote vs. local menus. I'm open to debate on that one, but I probably won't be the person to implement the split.

Lastly, I like your approach to adding a check for "xxxinfo items" in contextMenuQuery. Will try to get that in today as well.

I'll keep you posted.

cheers,
#!/ben

Slim::Menu::PlaylistInfo and the logic for contextMenuQuery() taking a menu:xxx and pushing a "xxxinfo items" command are both added, r26677.

Core items in PlaylistInfo are pretty sparse right now, just Play and Add. Also, I have not added any support for XMLBrowse playlists yet.

#!/ben

awy
2009-05-19, 03:51
RemoteTrack I'm not sure is necessary as TrackInfo already has code to handle remote vs. local menus. I'm open to debate on that one, but I probably won't be the person to implement the split.


I'm looking to harmonize the way remote-track info is handled so that in most cases the if (remote) { if ($handler->can('getMetadataFor')) ... stuff will go away. I don't have a detailed plan to share yet.

pippin
2009-05-20, 16:59
Am I correct to assume that



addAction => "more"


means that a context menu should be opened?
Any syntax behind this or is the MLON renderer meant to know how to create the context menu (as you described above)?