Announcement

Collapse
No announcement yet.

Announce: Material Skin

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

    Is this only with the 3.2 branch? Is master ok?
    Yup, going back fixed it. I reset local to origin/master, erased the cache, and on both the Android APK and in Firefox on my laptop, the Browse pane is back to working normally! I have not checked for error msgs yet on the refresh, but it is working again.
    Last edited by Ron F.; 2023-02-06, 23:22.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 18.04 + Squeezelite + Epiphany/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
    Bedroom: RPi Zero W + Squeezelite > miniBOSS DAC HAT > Bose SoundLink Revolve
    Phone: Pixel 6a + Termux/Squeezelite + Material APK > Senn IE80 earbuds
    Server: System76 Meerkat + Pop!_OS 22.04 + LMS 8.4

    Comment


      Originally posted by Ron F. View Post

      Yup, going back fixed it. I reset local to origin/master, erased the cache, and on both the Android APK and in Firefox on my laptop, the Browse pane is back to working normally! I have not checked for error msgs yet on the refresh, but it is working again.
      3.2 branch should be fixed now.
      Material debug: 1. Launch via http: //SERVER:9000/material/?debug=json (Use http: //SERVER:9000/material/?debug=json,cometd to also see update messages, e.g. play queue) 2. Open browser's developer tools 3. Open console tab in developer tools 4. REQ/RESP messages sent to/from LMS will be logged here.

      Comment


        Originally posted by cpd73 View Post

        3.2 branch should be fixed now.
        I reset my local to origin/3.2, testing on Melodeon, Android APK, Brave and Firefox browsers, and I think the issue is fixed: the Browse pane is now rendered properly.
        Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
        Laptop: System76 Galago + Ubuntu 18.04 + Squeezelite + Epiphany/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
        Bedroom: RPi Zero W + Squeezelite > miniBOSS DAC HAT > Bose SoundLink Revolve
        Phone: Pixel 6a + Termux/Squeezelite + Material APK > Senn IE80 earbuds
        Server: System76 Meerkat + Pop!_OS 22.04 + LMS 8.4

        Comment


          Originally posted by cpd73 View Post

          Material stores the setting in your browser's local storage. There you will find items sic as "lms-material::albums-grid"
          Thanks for the tip, I find also:

          "lms-material::album-grid"
          "lms-material::artists-grid"
          "lms-material::local-grid"
          "lms-material:: other-grid"
          "lms-material::music-grid"
          "lms-material::favorites-grid"
          "lms-material::browse-library-grid"
          "lms-material::qobuz-grid"

          Now of course I'm wondering where does the browser get the info from (album, artists, local, other, music, favorites, browse library and qobuz)?
          If you compare the default skin with the material skin, you will see that this functionality does not yet exist in the default skin. There it is really a global switch whose current value is stored in a cookie. Local storage is not used at all.
          From this I conclude that you also disliked the ugly behavior of a global grid/list switch and that you have therefore built in this distinction according to certain view types (album, artists, other, etc.).
          As you yourself have already written, this does not work for plugins, or there is only one global switch per plugin, which is of course unsatisfactory for plugins such as Qobuz, Spotify or Tidal etc.
          The question that now arises is whether it would be possible in some way to recognize which view type (album, artists, playlist, other) the currently displayed page is for each plugin.
          If this is not evident for Material-Skin from the data it gets from the server, one might think about what the plugin developer can do to change that. For example, one could provide a translation list per plugin from which the material skin can be seen what type of view it is. Or you derive the view type from the icon name of the menu item.
          But other methods would also be possible, in the end you choose the one that requires the least effort.
          I'd be very interested in allowing what works for the default views in material skin for plugins as well. The operation of the overall system would then also be more consistent.
          I'm also happy to help as much as I can.

          I know, I used that as an example of an item that is placed there - and when/how this happens.
          Ah ok, so it looks pretty bad for me to get an entry into this menu from a plugin.

          I read through the item "07 Customization - Custom menu entries and actions" on the GitHub page of Material-Skin in the wiki and tried to conjure up some additional menu according to this guide and the file "material-skin/actions.json", but I'm probably doing something wrong, because nothing changes with or without this file.
          Does this feature work at all?​​

          Comment


            Originally posted by sveninndh View Post
            Now of course I'm wondering where does the browser get the info from (album, artists, local, other, music, favorites, browse library and qobuz)?
            Material gets it from the first parameter of the JSONRPC request.

            Originally posted by sveninndh View Post
            The question that now arises is whether it would be possible in some way to recognize which view type (album, artists, playlist, other) the currently displayed page is for each plugin.
            Well if the response could indicate that the current view is a list of albums, artists, tracks, etc. then Material could use this to store the grid/list state.

            Originally posted by sveninndh View Post
            Ah ok, so it looks pretty bad for me to get an entry into this menu from a plugin.
            Well depends on what you want. I'm more than happy to make changes to accommodate plugin specific menu items here.

            Originally posted by sveninndh View Post
            I read through the item "07 Customization - Custom menu entries and actions" on the GitHub page of Material-Skin in the wiki and tried to conjure up some additional menu according to this guide and the file "material-skin/actions.json", but I'm probably doing something wrong, because nothing changes with or without this file.
            Does this feature work at all?​​
            Yes the feature works, I've just checked. However, this is meant for user or system integrators - not really for plugins.
            Last edited by cpd73; Yesterday, 18:49.
            Material debug: 1. Launch via http: //SERVER:9000/material/?debug=json (Use http: //SERVER:9000/material/?debug=json,cometd to also see update messages, e.g. play queue) 2. Open browser's developer tools 3. Open console tab in developer tools 4. REQ/RESP messages sent to/from LMS will be logged here.

            Comment

            Working...
            X