|
|
Re: Truly "dynamic" sitemaps [message #1369379 is a reply to message #1353047] |
Tue, 20 May 2014 15:02 |
Petr Klus Messages: 6 Registered: May 2014 |
Junior Member |
|
|
Hi Kai,
Sorry for not being more specific - I've only described the most simple use-case.
What I envision for the MPD binding to perform to truly replace any other UI would also be a more sophisticated track browser. This would require support of multiple levels of hierarchy - apart from flat playlist, I imagine access to tree-like artists, albums, tracks listings.
Also, in the track browser, it would be useful to have multiple buttons associated with each track - play next, add to playlist, add folder to playlist (for folders) - effectively mimicking web interface provided by volumio.org.
I have found hints on how to modify items lists in the OH, however, I am wondering how would the system perform if it had lists of thousands of items? Would I need to selectively populate the menus based on selected artist/album or could I simply re-create the whole structure in OH? It could potentially mean a list of 10k entries or more..
|
|
|
|
Re: Truly "dynamic" sitemaps [message #1376024 is a reply to message #1375997] |
Fri, 23 May 2014 08:17 |
Petr Klus Messages: 6 Registered: May 2014 |
Junior Member |
|
|
Hi Kai,
I agree - the basic core item structure should be kept as simple as possible. I was thinking further about your definition of the problem as being ultimately a selection widget and I think you are correct - I would prefer not to modify the item lists and structure just to populate artist/album lists.
In my opinion, having a dynamic selection widget supporting hierarchy would ultimately be the best - I think it would be a compromise between full-fledged browser with actions and just a track selection. At least for my use case, I imagine multiple entry-points for the selections - item that shows flat playlist for selection, then another item labeled "add to playlist" that would allow browsing through artists and adding them etc etc - user should be able to define filters in item definition, and binding would populate the widget when clicked.
What do you think?
I think that for me, OH is a must in the media control - I am after a multi room system with multiple MPD servers playing simultaneously and players able to select which pulseaudio pipe to listen to. To provide the glue in this system, OH is simply the best. Another best thing would be to be also able to control the music better - at this moment, I need to jump to another webpage with another UI.
Lastly, off-topic (but short) question - I've given up waiting on the official Java api from LIFX guys and starting with unofficial api integration - I am mirroring the Phillips Hue extension, however, I saw that SmartHome will have different binding API - when is this going to be out/is it worth waiting for? Would old-style extensions and addons still be compatible?
|
|
|
Re: Truly "dynamic" sitemaps [message #1376285 is a reply to message #1376024] |
Fri, 23 May 2014 10:42 |
Kai Kreuzer Messages: 673 Registered: December 2011 |
Senior Member |
|
|
Petr Klus wrote on Fri, 23 May 2014 10:17In my opinion, having a dynamic selection widget supporting hierarchy would ultimately be the best
The question is whether this is a new kind of widget or if it is simply a dynamically generated sitemap page, which then provides the possible titles as mappings for the selection widget. Not sure, what is the best way. Another problem is the switch from a flat list to a tree structure - this would actually imply that we need both: a new widget type (a TreeSelectionWidget) which is then dynamically filled by a dynamic "playlist" sitemap.
Petr Klus wrote on Fri, 23 May 2014 10:17I saw that SmartHome will have different binding API - when is this going to be out/is it worth waiting for? Would old-style extensions and addons still be compatible?
A good question. For openHAB 2.0, I am planning a 1.x compatibility layer, so that (most) current addons can still be used. Nonetheless on the long run, bindings should be moved to the new APIs, but currently it is still too early for this. Most of the work in the bindings is usually the device specific stuff (i.e. how to access and control the LIFX) and thus I would not think that migrating a binding from 1.x to 2.x means a rewrite, but that major parts can be kept.
|
|
|
Powered by
FUDForum. Page generated in 0.03989 seconds