Media API -- too much?

[pcp]

For the Search, I could define a device with VSPairs, I can create a device as below

SearchRef = hs.GetDeviceRef("Media Search")
If SearchRef <= 0 Then SearchRef = hs.NewDeviceRef("Media Search")

dv = hs.GetDeviceByRef(SearchRef)
dv.Address(hs) = "SqueezeBox-Search"

dv.Location(hs) = IFACE_NAME
dv.Last_Change(hs) = Now
dv.Device_Type_String(hs) = "Search Device"
dv.Interface(hs) = IFACE_NAME
dv.InterfaceInstance(hs) = instance

hs.DeviceVGP_ClearAll(dv.Ref(hs), True)
hs.DeviceVSP_ClearAll(dv.Ref(hs), True)

Pair = New VSPair(HomeSeerAPI.ePairStatusControl.Both)
Pair.PairType = VSVGPairType.SingleValue
Pair.Value = 1
Pair.Status = ""
Pair.Render = Enums.CAPIControlType.TextBox_String
hs.DeviceVSP_AddPair(dv.Ref(hs), Pair)

hs.SetDeviceValueByRef(dv.Ref(hs), 1, True)
dv.MISC_Set(hs, Enums.dvMISC.SHOW_VALUES)

When a search is submitted, my plugin SetIOMulti is called and I can determine what I need to do with this actio, how I want to represent the result (html in device string, content of a list in another device, etc) and which devices to update (including the NavBrowser). Of course instead of a Enums.CAPIControlType.TextBox_String I could use another like a select one in a list of predefined searches.

Note that from a plugin point if view I do not deal with the UI/Rendered which can be jQuery object, HSTouch UI, JSon, CAPI script call, etc From my point of view, I think we have all the (device & VSPair) constructs we need today.

[pcp]

For the NavSearch, I can construct it as follows with some caveats I will cover later

MediahRef = hs.GetDeviceRef("Media Browse")
If MediahRef <= 0 Then MediahRef = hs.NewDeviceRef("Media Browse")

dv = hs.GetDeviceByRef(MediahRef)
dv.Address(hs) = "SqueezeBox-Browse"

dv.Location(hs) = IFACE_NAME
dv.Last_Change(hs) = Now
dv.Device_Type_String(hs) = "Browse Device"
dv.Interface(hs) = IFACE_NAME
dv.InterfaceInstance(hs) = instance

hs.DeviceVGP_ClearAll(dv.Ref(hs), True)
hs.DeviceVSP_ClearAll(dv.Ref(hs), True)

Pair = New VSPair(HomeSeerAPI.ePairStatusControl.Both)
Pair.PairType = VSVGPairType.SingleValue
Pair.Value = 1
Pair.Status = ""
Pair.Render = Enums.CAPIControlType.List_Text_from_List
Pair.StringList = {"Featured", "Local Stations", "Shows", "Stations"}
hs.DeviceVSP_AddPair(dv.Ref(hs), Pair)

hs.SetDeviceValueByRef(dv.Ref(hs), 1, True)
dv.MISC_Set(hs, Enums.dvMISC.SHOW_VALUES)

In the above example and for simplicity, I a fixed list of choices in but could call one of the media APIs to get the list of radio stations, genres, tracks. etc This renders as follows (see screenshot)

I can pick and choose my 0 to N options and SetIOMulti is called upon change and have context to device what to do and which devices to update. I can drill down to details (albums, tracks, radios by country, etc), go up to parent (pick the media library such MyMusic, Spotify, etc), play a song, update the ControlStringList, show the selected as a comma separated list in the device string, etc

So what are the caveats, limitations

• StringList and StringListAdd only lets me provide a list of strings to display. I need to be able to provide a name/value list [and value is the hidden and not to be confused with the device value] where value is hidden as Dirk refers to it above. The name is used for display purpose and the value should be a string and I can serialize into it what I want (from a plugin point of view) to provide context when SetIOMulti is called. I would use this value as the "bread crum" to understand where each entry in the list is in terms of tree nativigation ,can reconstruct the location in SetIoMulti and use this to find children or parent nodes, to play the content of that node (track, album, etc). EDIT: in addition to the name, hidden value structure, it should also support specifying an URL to an icon per entry.
• In some cases I do not want to support multi selection, but rather single selection still providing a list as above. Enums.CAPIControlType.Single_Text_from_List appears to be the natural choice but could never get it to work
• The renders in the web page should be a jqListBoxEx instead of the jqMultiSelect or at least optionally (i.e. a preference option in the VSPair)
• HSTouch should support association (in a listbox or combobox) with such a device and retrieve the content from the ControlStringList.
• I used StringList and StringListAdd above and existing Enums.CAPIControlType but new one list could be defined if needed and more approapriate. The content of the list does not need to be permanent (in HS3 and in the DB) as the plugin can populate it when it starts with default values (if that helps from a performance point of view)
• Are dv.StringList and dvStringListAdd the best APIs to refresh the content of the list in the plugin or should new ones be defined? For HS to define and let us know
• SetIoMulti should include an optional argument to tell us a bit more how the selection was made (single click, double click, shift+click) as Dirk mentioned earlier.
• Are dv.StringList and dvStringListAdd the best APIs to update the content of the list in the plugin or should new ones be defined? For HS to define and let us know
• Need an API or dv.StringListSelected field to let us specify which one(s) are currently selected in the list
• The above constructs are not client specific. Any browse change (content of list) would affect all clients. Not ideal but and could add some id to the StringList and SetIOMulti to identify the client(s). At the same time how often do we have customers browsing the media for the same player (i.e. I would have one browse device per player) at the same time? Is this something where we could define the approach but build incrementally while we get the base done first?

So I believe the current VSPAir contructs and options are not that far off from what we are looking for and what Dirk described above. I am not sure and have not tested the HSTouch integration (UI control and association) for the above renderer, how hard it would be for HS to wire them together and how to extend the Enums.CAPIControlType.List_Text_from_List or define a new one to cover the gaps. Overall this would be much closer to the core HS3 approach, go beyond HSTouch (JSON, CAPI scripting, future JSON UI, etc) and provide greater flexibility.


What do you all think? What could be the gotach's or other gaps not identified?


The Media API would end up (possibly) similar the other APIs (Thermostat) limited to deviceTypeInfo identification (api/type/subtypes).

[pcp]

And understand the desire to come up with HSTouch template screens,... maybe achievable using the media API devices as plugin name/plugin instance/devices deviceTypeInfo identification (api/type/subtypes) to define scope, but this should be separate.

Focusing on defining the core contracts (plugin/HS3) and having them working efficiently (i.e. notification versus poll, etc) + keep it simple within existing good HS3 frameworks (VSPair for example) to minimize maintenance burden (for HS3), dependencies (HS needs to example to expand media API as plugin others need more, or users/plugin authors are frustrated to to lack of core constructs), + expand the breadth (HSTouch, JSON, CAPI scripting, etc) is key to me. The starter template in HSTouch are secondary to me.

[pcp]

The squeezebox plugin has an action that let's you play something and the UI includes a media browser (jqListboxEx) that is similar to what's described above: list with name/value (value = hidden breadcrums defiend by the plugin author), callbacks as selections happen and plugin decides what next, etc. Quite similar to above except we have a VSPair, StringList/StringListAdd (or better/similar APIs) and SetIOMUlti and without an external/published media API.

[dcorsus]

The squeezebox plugin has an action that let's you play something and the UI includes a media browser (jqListboxEx) that is similar to what's described above: list with name/value (value = hidden breadcrums defiend by the plugin author), callbacks as selections happen and plugin decides what next, etc. Quite similar to above except we have a VSPair, StringList/StringListAdd (or better/similar APIs) and SetIOMUlti and without an external/published media API.

Thanks Philippe, great contributions!!!
I have exactly the same implementation !!!

For the NavSearch, I can construct it as follows with some caveats I will cover later

MediahRef = hs.GetDeviceRef("Media Browse")
If MediahRef <= 0 Then MediahRef = hs.NewDeviceRef("Media Browse")

dv = hs.GetDeviceByRef(MediahRef)
dv.Address(hs) = "SqueezeBox-Browse"

dv.Location(hs) = IFACE_NAME
dv.Last_Change(hs) = Now
dv.Device_Type_String(hs) = "Browse Device"
dv.Interface(hs) = IFACE_NAME
dv.InterfaceInstance(hs) = instance

hs.DeviceVGP_ClearAll(dv.Ref(hs), True)
hs.DeviceVSP_ClearAll(dv.Ref(hs), True)

Pair = New VSPair(HomeSeerAPI.ePairStatusControl.Both)
Pair.PairType = VSVGPairType.SingleValue
Pair.Value = 1
Pair.Status = ""
Pair.Render = Enums.CAPIControlType.List_Text_from_List
Pair.StringList = {"Featured", "Local Stations", "Shows", "Stations"}
hs.DeviceVSP_AddPair(dv.Ref(hs), Pair)

hs.SetDeviceValueByRef(dv.Ref(hs), 1, True)
dv.MISC_Set(hs, Enums.dvMISC.SHOW_VALUES)

Great suggestion. Only add I would stress, and you wrote it somewhere below, that we should agree on the Device_API and Device_Type enums. My recommendation is to come up with specific ones so it will be easier for HST Designer and their clients to logically group all devices that logically belong together. I see different ways that people could use this but for Sonos for example, I would combine the player control functions with the content navigation functions and the queue management functions because that's what one Sonos player does. For DLNA devices, I could envision that a DLNA content server just has the navtree functions. Come to think about it, there are 3 major components to managing players, ie control functions (via HS controls), Media selection (via new NavTree) and Queue/Playlist management (via combination of NavTree and Controls). Reason I bring it up, if the HS team does decide to try to logically combine functions to make it easier to design HST Media screens, they may think of a Content Navtree and Queue/Playlist Navtree concept. So instead of having the "music" option to chose from in HST Designer (which then subsequently allow you to select track, album etc), you may have a few options like PlayerControl, ContentNav, QueueManagement .... and show in subsequent menu the options the PI author created which could be play,pause,track, year ... for player control; could be load Movies, Music, genre, rating etc for NavTrees and add track, delete track for Queue management.

In the above example and for simplicity, I a fixed list of choices in but could call one of the media APIs to get the list of radio stations, genres, tracks. etc This renders as follows (see screenshot)

Wonder whether we should come up with some standard syntax (we would recommend to PI authors but free to implement or ignore) on the search syntax. Something like "get all tracks by author U2" ... Actually makes me wonder at which point we (or us and HS) should put some of the code in the open source space on GitHub where we collaborate for example on parsing code for a "search Syntax parser" or "development sample (beyond what is already provided by HS)" ....

Another implementation of entering search info, which impacts all your HST clients is a mechanism Sonos is using. They have a combined control which has a text entry section and a drop-down-list section. In the drop down you have options like tracks, albums, genre etc so you select what you want to search and enter in the text area what you are searching for. If we could implement this, the PI author would actually populate the search options to chose from and text entered would return both the search txt and the selected search option. Just a thought.

So what are the caveats, limitations

• StringList and StringListAdd only lets me provide a list of strings to display. I need to be able to provide a name/value list [and value is the hidden and not to be confused with the device value] where value is hidden as Dirk refers to it above. The name is used for display purpose and the value should be a string and I can serialize into it what I want (from a plugin point of view) to provide context when SetIOMulti is called. I would use this value as the "bread crum" to understand where each entry in the list is in terms of tree nativigation ,can reconstruct the location in SetIoMulti and use this to find children or parent nodes, to play the content of that node (track, album, etc)?

This to me is THE most important requirement!!

• In some cases I do not want to support multi selection, but rather single selection still providing a list as above. Enums.CAPIControlType.Single_Text_from_List appears to be the natural choice but could never get it to work

Quite important as well, not just the fact that we can have the option for multiple selection but that we can control it.

What is crucial for me is the ability to distinguish single from double click events. For example, I use a double click event to indicate that the user decided that he/she wants to play what she just double clicked, which could be an entire album or entire genre, whereas single clicks will indicate, navigate down

• The renders in the web page should be a jqListBoxEx instead of the jqMultiSelect or at least optionally (i.e. a preference option in the VSPair)
• HSTouch should support association (in a listbox or combobox) with such a device and retrieve the content from the ControlStringList.
• I used StringList and StringListAdd above and existing Enums.CAPIControlType but new one list could be defined if needed and more approapriate. The content of the list does not need to be permanent (in HS3 and in the DB) as the plugin can populate it when it starts with default values (if that helps from a performance point of view)
• Are dv.StringList and dvStringListAdd the best APIs to refresh the content of the list in the plugin or should new ones be defined? For HS to define and let us know
• Are dv.StringList and dvStringListAdd the best APIs to update the content of the list in the plugin or should new ones be defined? For HS to define and let us know
• Need an API or dv.StringListSelected field to let us specify which one(s) are currently selected in the list

Indeed

• SetIoMulti should include an optional argument to tell us a bit more how the selection was made (single click, double click, shift+click) as Dirk mentioned earlier.

Actually add to that "delete", "drop", "start drag" (see below)

• The above constructs are not client specific. Any browse change (content of list) would affect all clients. Not ideal but and could add some id to the StringList and SetIOMulti to identify the client(s). At the same time how often do we have customers browsing the media for the same player (i.e. I would have one browse device per player) at the same time? Is this something where we could define the approach but build incrementally while we get the base done first?

Thought about that as well, will increase complexity quite a bit because so far, we can depend on standard "Device technology" where we change a device and all clients gets updated. If we change this, I think the change is major, not to mention if client come and go on-off line, how do you sync em. I suggest we live with the restriction unless someone has a great idea?

What do you all think? What could be the gotach's or other gaps not identified?

We could define a limited set of standard built in functions for this NavTree component. For example: a standard "back" button so you don't have to add fake entries or specific buttons to allow back navigation.
A parameter to allow multiple/single selections
A parameter to set highlighted entry or entries
A max entries parameter, combine with start index parameter (?)
A filter parameter (just used locally on clients)
A "delete" event, when a selection was made and the delete button was clicked (best for queue management)
Actions upon right click events

Perhaps not urgent but if we think about queue management, the best way to do it is when you can have two navTrees side by side, with one showing server content to select from and the other the playlist or queue you have. We could do this with PI author defined buttons like "add to playlist, remove etc" but better would be drag and drop. That would mean that the NavTree would need to send an event like "x-entries dropped"

So I believe the current VSPAir contructs and options are not that far off from what we are looking for and what Dirk described above. I am not sure and have not tested the HSTouch integration (UI control and association) for the above renderer, how hard it would be for HS to wire them together and how to extend the Enums.CAPIControlType.List_Text_from_List or define a new one to cover the gaps. Overall this would be much closer to the core HS3 approach, go beyond HSTouch (JSON, CAPI scripting, future JSON UI, etc) and provide greater flexibility.

The Media API would end up (possibly) similar the other APIs (Thermostat) you have as a deviceTypeInfo idendification (api/type/subtypes).

Yup

[pcp]

Per request from Rich, below is a proposal to expand the CAPI/VSPair to support an item browser that can then be used to navigate media (or other). I focused on CAPI & VSPair and not on additional device media type/subtypes. I also made it very specific to the existing APIs instead of long English descriptions.



- Expand CAPIControlType
--- Add New Enum type ITEM__LIST_BROWSER = 14 to CAPIControlType
--- Typical renderer is jqLIstBoxEx, ListBox in HSTouch, etc...

- New definitions and class
--- definition are just ideas, not applicable for all clients and of course could be expanded
Public Const CAPI_CONTROL_Single_Click as Integer = 1
Public Const CAPI_CONTROL_Double_Click as Integer = 2
Public Const CAPI_CONTROL_Shift_Key as Integer = 8
Public Const CAPI_CONTROL_Control_Key as Integer = 16
Public Const CAPI_CONTROL_Alt_Key as Integer = 32
Public Const CAPI_CONTROL_Delete_Key as Integer = 64
Public Const CAPI_CONTROL_Backspace_Key_or_Swipe as Integer = 128
Public Const CAPI_CONTROL_Enter_Key_or_Swipe as Integer = 256
Public Const CAPI_CONTROL_Right_Arrow_Key_or_Swipe as Integer = 512
Public Const CAPI_CONTROL_Left_Arrow_Key_or_Swipe as Integer = 1024

Public Class CAPIControlItem
Inherits MarshalByRefObject
Public name As String ' display name in renderer
Public icon as String ' URL (file:.., http..., C:/ etc) to display icon for entry if suported by renderer
Public key as String ' hidden key value as string. May contain simple strings. xml or serialized object
Public selected as Boolean ' If true item is currently selected and should be highlighted in renderer
Public hasChildren as Boolean ' If true item has children and renderer can add an indicator (like right arrow or >) in display to indicate that additional navigation is supported.
End Class

- New Enum
Enum.CAPIControlListItem
Single_selection = 0 ' Allows single selection only
Multi_selection = 1 ' Allows selection of multiple items
End Enum


- Expand VSPair
--- Maybe a new VSVGPairType might be required, not sure. VSPair
--- ListIemType and ListItems will be updated while browsing navigating to parent or children of items during a call to SetIOMulti
Public Class VSPair
Public PairType As VSVGPairType
Public Render_Location As Enums.CAPIControlLocation
Public RangeStart As Double
Public RangeEnd As Double
Public RangeStatusPrefix As String = ""
Public RangeStatusSuffix As String = ""
Public RangeStatusDecimals As Integer = 0
Public RangeStatusDivisor As Double = 0
Public IncludeValues As Boolean = True
Public ValueOffset As Double = 0
Public HasAdditionalData As Boolean = False
Public HasScale As Boolean = False
Public ZeroPadding As Boolean = False
Public Const ScaleReplace As String = "@S@"
Public Shared Function AddDataReplace(ByVal Index As Integer) As String
Public ReadOnly Property ControlStatus As ePairStatusControl
Public Property Render As Enums.CAPIControlType
Public PairButtonImageType As Enums.CAPIControlButtonImage
Public PairButtonImage As String
Public WriteOnly Property Status As String
Public Property Value As Double
Public Property StringList As String()
Public WriteOnly Property StringListAdd As String
Public WriteOnly Property ListAdd As String
Public Property ControlUse As ePairControlUse
' Note: Below only relevant for CAPIControlType = ITEM__LIST_BROWSER. Content of ListItems does not need to be permanent, the plugin could rebuild it at startup
Public Property ListIemType as Enum.CAPIControlListItem ' NEW --
Public Property ListItems As CAPIControlItem() ' NEW -- If possible in HS3 a System.Collection (Hastahble, SortedList, ..) would be preferred
Public WriteOnly ListItemAdd As CAPIControlItem ' NEW -- adds a new item to ListItems collection/array
End Class

- Expand CAPIControl
Public Class CAPIControl
Inherits MarshalByRefObject
Public Do_Update As Boolean
Public SingleRangeEntry As Boolean
Public Property CCIndex As Integer
Public Property Range As clsValueRange
Public ReadOnly Property Ref As Integer
Public Property Label As String
Public Property ControlType As Enums.CAPIControlType
Public ControlButtonType As Enums.CAPIControlButtonImage
Public ControlButtonCustom As String
Public Property ControlLocation As Enums.CAPIControlLocation
Public Property ControlLoc_Row As Integer
Public Property ControlLoc_Column As Integer
Public Property ControlValue As Double ' NEW --- When CAPIControlType = ITEM__LIST_BROWSER, index of first item in ListItems that is selected in action ???
Public Property ControlString As String = "" ' NEW --- When CAPIControlType = ITEM__LIST_BROWSER, comma separated list of CAPIControlItem.name of the items that were selected ???
Public Property ControlStringList() As String()
Public Property ControlFlag As Boolean
Public Property ControlUse As ePairControlUse
' Note: Below only relevant for CAPIControlType = ITEM__LIST_BROWSER
Public Property ListIemType as Enum.CAPIControlListItem ' NEW --
Public Property ListItems As CAPIControlItem() ' NEW -- If possible in HS3 a System.Collection (Hastahble, SortedList, ..) would be preferred
Public ReadOnly Property ControlSelectionItems As Integer() ' NEW --- When CAPIControlType = ITEM__LIST_BROWSER, array of indices in ListItems that are selected with action that triggered call to SetIOMulti
Public ReadOnly Property ControlSelectionType as Integer ' Bit mask of CAPI_CONTROL_* to indicate details of change action
End Class

SetIOMulti
- Similar to other renderers, when a change occurs in the control for CAPIControlType = ITEM__LIST_BROWSER, SetIOMulti is called
- CAPIControl.ControlItemIndices and CAPIControl.ControlSelectionType provides details of changes/selection in the renderer
- SetIOMulti call might modify content of VSPair.ListIemType and VSPair.ListItems

[pcp]

One drawback of using the current VSPAir is that any changes of the content of ListItems impact all clients (HSTouch screens, Device manager page, etc), i.e. all clients will always show the same for a given device/VSPair. By using one device per player this would be limited to a single player, which should be ok; I do not think many have tow people browsing the media library for the same player at the same time... feels like an edge case. I am (And Dirk as well per above) willing to live with this. Maybe Rich has an idea how to add client specifics to the CAPIControl, not sure.

[pcp]

Media API -- too much?

I have been busy in the last few weeks, maybe missed some threads. Has there been any update / decision on how we will move forward with the media api? Any activity in terms of implementation / bug fixes?


Sent from my iPad using Tapatalk

[dcorsus]

I have been busy in the last few weeks, maybe missed some threads. Has there been any update / decision on how we will move forward with the media api? Any activity in terms of implementation / bug fixes?

I've been on the road myself for the last 2 months and haven't fully studied your proposal, albeit it looked good.
Dirk

[pcp]

Happy New Year to all!

Rich any update on how to proceed with the media stuff? Are you looking into this approach via devices or keep the original fixing the different bugs? Thanks

[rjh]

I like using devices, I think it simplifies things. I want to understand why you need a new listbox as we already have one, it looks like you want the following new features, correct?

* Ability to add an icon to the list, most likely at the left of the list entry
* Ability to add a value to a string list entry

Both of those could be added to the existing control type:

Enums.CAPIControlType.List_Text_from_List

I can make those changes to the existing control type, and also I need to handle cases where a plugin changes this list at will, which means I need to notify HSTouch clients so they can re-load the list, as well as the HS UI.

Happy New Year to all!

Rich any update on how to proceed with the media stuff? Are you looking into this approach via devices or keep the original fixing the different bugs? Thanks

[pcp]

I like using devices, I think it simplifies things. I want to understand why you need a new listbox as we already have one, it looks like you want the following new features, correct?

* Ability to add an icon to the list, most likely at the left of the list entry
* Ability to add a value to a string list entry

Both of those could be added to the existing control type:

Enums.CAPIControlType.List_Text_from_List

I can make those changes to the existing control type, and also I need to handle cases where a plugin changes this list at will, which means I need to notify HSTouch clients so they can re-load the list, as well as the HS UI.

Thanks Rich for the update. I also like using devices. Once we have that the media API is just a list of device type/subtypes IDs like the Thermostat API and bet it will simplify your support as well.

Key requirements expanded from your list
* Extending Enums.CAPIControlType.List_Text_from_List is fine and do not need a new one as long as it can support the functionality
* Per entry in the list be able to specify: a display name, a key value (hidden as a string), a icon url/, a selected boolean, a hasChildren boolean (can be used in list box rendered to indicate on the right that it has children like via a arrow, > sign, etc). the current Enums.CAPIControlType.List_Text_from_List I understand only let's you specify a vector of strings and the ask is to specify a vector of structures (or objects) like the CAPIControlItem I suggested above.
* CAPIControl in SetIOMulti to specify the selected item(s) and "selection action" (single click, double click, delete key, etc -- see above CAPI_CONTROL_* constants)
* Support via configuration for single or multiple selection in list control (Enums.CAPIControlType.List_Text_from_List only supports single selection if I recall)
* Ability to add a value to a item list entry
* Ability to remove a value to a item list entry
* Ability to add an icon to the list, most likely at the left of the list entry

[rjh]

To help me understand, can you give me a list of things that you want to put in this list and the type of actions you want? Some parts of the list would be owned by HS only, and other parts would be passed along to HSTouch. I would think the icon, text, and value would be passed to HSTouch and the object would only be accessible from a plugin.

Note that if I only stored a value, you could easily keep your own DB that you could reference using the value, so does HS really need to keep any plugin specific object? The more we store in there, the slower it will be to load/display the list and the more memory HS will be using. Makes things easy for me if I only need to add an icon and a value to the string list!

I asked Spud if he was ok with all of this since I did not see him chime in and he said he was, so looks like all media authors are on board.

To address your issue with users, I could add a user component to any dynamic list (maybe we add a dynamic property to the vspairs). If this is set, I will keep multiple lists, one per user. This way you can load a list with media for a specific user and it will only change the list on the HSTouch client for that user (and web UI). The HSTouch plugin already has user info.

Thanks Rich for the update. I also like using devices. Once we have that the media API is just a list of device type/subtypes IDs like the Thermostat API and bet it will simplify your support as well.

Key requirements expanded from your list
* Extending Enums.CAPIControlType.List_Text_from_List is fine and do not need a new one as long as it can support the functionality
* Per entry in the list be able to specify: a display name, a key value (hidden as a string), a icon url/, a selected boolean, a hasChildren boolean (can be used in list box rendered to indicate on the right that it has children like via a arrow, > sign, etc). the current Enums.CAPIControlType.List_Text_from_List I understand only let's you specify a vector of strings and the ask is to specify a vector of structures (or objects) like the CAPIControlItem I suggested above.
* CAPIControl in SetIOMulti to specify the selected item(s) and "selection action" (single click, double click, delete key, etc -- see above CAPI_CONTROL_* constants)
* Support via configuration for single or multiple selection in list control (Enums.CAPIControlType.List_Text_from_List only supports single selection if I recall)
* Ability to add a value to a item list entry
* Ability to remove a value to a item list entry
* Ability to add an icon to the list, most likely at the left of the list entry

[pcp]

To help me understand, can you give me a list of things that you want to put in this list and the type of actions you want? Some parts of the list would be owned by HS only, and other parts would be passed along to HSTouch. I would think the icon, text, and value would be passed to HSTouch and the object would only be accessible from a plugin.

Note that if I only stored a value, you could easily keep your own DB that you could reference using the value, so does HS really need to keep any plugin specific object? The more we store in there, the slower it will be to load/display the list and the more memory HS will be using. Makes things easy for me if I only need to add an icon and a value to the string list!

I asked Spud if he was ok with all of this since I did not see him chime in and he said he was, so looks like all media authors are on board.

To address your issue with users, I could add a user component to any dynamic list (maybe we add a dynamic property to the vspairs). If this is set, I will keep multiple lists, one per user. This way you can load a list with media for a specific user and it will only change the list on the HSTouch client for that user (and web UI). The HSTouch plugin already has user info.

Thank you checking with Spud, I was concerned as well that he did not chime in. I (and bet others as well) agree to keep the interface as simple as possible. I am not fully following your suggestion: are you suggesting to encode (html tag?) the icon URL in the existing string list? Would the value be a separate vector of string or integer, or encoded in the existing string list? Either approach would work.

If multiple items are selected in the listbox, would setMultiIO be called once for all selected entries or called multiple times once for each selected item?

Again just need to understand how you want to design it, implement it and makes most sense within the existing HS3 architecture.

[dcorsus]

To help me understand, can you give me a list of things that you want to put in this list and the type of actions you want? Some parts of the list would be owned by HS only, and other parts would be passed along to HSTouch. I would think the icon, text, and value would be passed to HSTouch and the object would only be accessible from a plugin.

Note that if I only stored a value, you could easily keep your own DB that you could reference using the value, so does HS really need to keep any plugin specific object? The more we store in there, the slower it will be to load/display the list and the more memory HS will be using. Makes things easy for me if I only need to add an icon and a value to the string list!

I asked Spud if he was ok with all of this since I did not see him chime in and he said he was, so looks like all media authors are on board.

To address your issue with users, I could add a user component to any dynamic list (maybe we add a dynamic property to the vspairs). If this is set, I will keep multiple lists, one per user. This way you can load a list with media for a specific user and it will only change the list on the HSTouch client for that user (and web UI). The HSTouch plugin already has user info.

I think I'd be fine with just an Object Value or ID.

On top of having:
1/ an icon_URL or image_URL capability in the "visible" part
2/ the capability to have multiple selections
3/ to have event notifications such as single click, double click, cntrl click, shift left/right click would be quite important
4/ The ability to control which events (say only single click, single selection)
5/ the ability to highlight entries would be important as well.

A while back, I envisioned this listbox to be the replacement of the MediaAPI. This would have meant that if you were in the HSDesigner and selected Music (or Media), you would be presented with Media items (players, servers..) to control and associated controls (back button, load xyz ...). It would have been a lot more user friendly for HST designers out there but it would have meant that we had to all agree on some "discovery" protocol, where HST Designer would query Media PIs for info. In the same vein, the proposal was to start with a "Media dedicated" Device_Type type (DeviceTypeInfo.eDeviceType_Media.Root perhaps :-)), where this list box obviously would be front and center, but Media PI authors would add other controls to this device and HST could present all the controls as a combined set when selected by a designer. Do I make sense?

Example: I would create ONE HS device_type Media.root, add the list box, add buttons such as "back", "all genres", "all tracks", "pause", Play" ... Which is is pretty much what I'm doing today, just that I don't have the listbox nor will HST Designer show this grouped as the "new Media API". If we were to now let's say add a "pair type" to the VSPair, we could now enforce some proper use of types which will make it even easier for HST Designer to figure out where, for example, the play button is.

As I said, this was a long time ago, I'll settle for the MediaListbox

Cheers, Happy New Year and best wishes for 2016. Any of you going to CES2016 this week? We could hook up.

Dirk