Announcement

Collapse
No announcement yet.

Media API -- too much?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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.
    Attached Files

    Comment


    • #17
      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).


      Attached Files
      Last edited by pcp; November 15th, 2015, 02:28 PM. Reason: Fixed type and added note that we want to specify icons

      Comment


      • #18
        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.

        Comment


        • #19
          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.
          Attached Files
          Last edited by pcp; November 14th, 2015, 11:13 AM.

          Comment


          • #20
            Originally posted by pcp View Post
            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 !!!

            Originally posted by pcp View Post
            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.

            Originally posted by pcp View Post
            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.

            Originally posted by pcp View Post
            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!!

            Originally posted by pcp View Post
            • 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

            Originally posted by pcp View Post
            • 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

            Originally posted by pcp View Post
            • 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)

            Originally posted by pcp View Post
            • 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?


            Originally posted by pcp View Post
            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"

            Originally posted by pcp View Post
            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

            Comment


            • #21
              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
              Last edited by pcp; November 22nd, 2015, 09:07 AM. Reason: Made a few revisions to proposal

              Comment


              • #22
                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.

                Comment


                • #23
                  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

                  Comment


                  • #24
                    Originally posted by pcp View Post
                    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

                    Comment


                    • #25
                      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

                      Comment


                      • #26
                        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.

                        Originally posted by pcp View Post
                        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
                        website | buy now | support | youtube

                        Comment


                        • #27
                          Originally posted by rjh View Post
                          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

                          Comment


                          • #28
                            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.

                            Originally posted by pcp View Post
                            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
                            website | buy now | support | youtube

                            Comment


                            • #29
                              Originally posted by rjh View Post
                              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.

                              Comment


                              • #30
                                Originally posted by rjh View Post
                                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

                                Comment

                                Working...
                                X