>From what I remember about the BrowseDB/mixer internals I'm pretty sure I wouldn't be able to provide a meaningful patch as it was very difficult to follow - that's probably as much to do with my understanding of Perl shorthand as a comment on the complexities of the code, though.
So, unfortunately, I don't think I'd stand much chance of tackling that on my own. I think 3.0 will work OK at the moment if you fix the compatibility settings in install.xml, so I think I'll leave it as it is until such time as a better API comes along. Stuart erland wrote: > hickinbottoms;336860 Wrote: > >> I did that because I was never happy calling that internal function as >> it took some bodging to make it work - I had to add some attributes to >> my mode's hash to fool that internal mixing function it was being >> called >> from the BrowseDB mode and not my lazy search results mode, for >> example >> - that always looked too fragile to me. >> >> > I completely agree, the whole mixer API needs to be refactored, it is > today very dependent on the BrowseDB menu structure data. I started to > make a patch once, but stopped after a while because it felt like it > required too much changes to get a chance to be approved. > > I'll have a look at it again if I get the time. > > hickinbottoms;336860 Wrote: > >> Do you know of a more stable API that lets any mixer get involved, >> similar to how BrowseDB must work internally but without needing to >> call >> 'private' functions? I'd happily move to that. >> >> > I believe there aren't any public ways of launching mixers, the mixer > launching code and even worse the implementation of the mixers > themselves are today very dependent on that the caller looks exactly > like the BrowseDB structure data. > > I have to look into again to make sure, but I think it might just be > luck that it worked in 3.0. > > hickinbottoms;336860 Wrote: > >> Failing that I could revert the change, but I'd prefer a stable API >> version if possible. >> >> > Instead of reverting I would suggest to look if it is possible to > provide a patch to change the SqueezeCenter internals to make a more > public mixer API. Let me know if you like to try to do this and want > the code I started on and I'll try to find it. > > I've had the exact same problem in Custom Browse and decided to > re-implement the mixing code as a Custom Browse specific mixer API > which is a bit less dependent on who the caller is. The disadvantage of > this is that no standard mixers work for Custom Browse, so I > re-implement the MusicIP mixer by using a private function in the > MusicIP plugin and implement duplicate mixers in all my other plugins, > one when launched from BrowseDB and one when launched from Custom > Browse. > > As you probably remember, there is an enhancement request available > regarding this: > http://bugs.slimdevices.com/show_bug.cgi?id=4451 > > > _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
