Announce: Material Skin

[Ron F.]

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.

[cpd73]

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.

[Ron F.]

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.

[sveninndh]

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?

[cpd73]

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.

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.

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.

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.