[Announce] Squeezelite-X

[rgdawson]

At least once a day. Right now, for example.

When it happens, try just pressing F5, which should refresh the browser, and let me know if that "fixes" it. Maybe there is a timing issue related to SLX manipulating Material Skin's local storage at precisely the wrong time. I'm investigating, just hard because I cannot reproduce it.

R Greg Dawson

[dolodobendan]

When it happens, try just pressing F5, which should refresh the browser, and let me know if that "fixes" it. Maybe there is a timing issue related to SLX manipulating Material Skin's local storage at precisely the wrong time. I'm investigating, just hard because I cannot reproduce it.

R Greg Dawson

I'll try that, thank you.

Speaking of trying, I tested the Material Skin Filter (let's just call it MSF) on the Surface and it didn't work either. (That doesn't make me unhappy or whatever, just letting you know. )

[rgdawson]

I applied the changes, even restarted SLX. The filter is enabled, but I guess it's nothing in this case (I checked against your "what should happen" list.)

Alright, I have an explanation for this. I am betting that you are using the MaterialSkin plugin, rather than manually copying the Material Skin files off of GitHub and manually copying them on the server. I do the latter because I am always getting the latest so I can test it. What I didn't realize until now is that the official plugin, installed through LMS, works differently. I don't know if it is using compression or something, but I'll figure it out.

So for 2.4.4, the filter only works if you have installed Material Skin manually.

I'll see if I can handle both cases

R Greg Dawson

[rgdawson]

My bad, sorry. I only skimmed the release notes and thought it was enabled by default.

Edit: Um, but yes, I do see the collapsible sections with the Material Skin Filter enabled...

OK, I discovered that the official version uses different resource names, e.g. toolbar.min.js versus toolbar.js, so now I have this working with the minify version.

R Greg Dawson

[dolodobendan]

Alright, I have an explanation for this. I am betting that you are using the MaterialSkin plugin, rather than manually copying the Material Skin files off of GitHub and manually copying them on the server.

Yes. Call me lazy.

I do the latter because I am always getting the latest so I can test it. What I didn't realize until now is that the official plugin, installed through LMS, works differently. I don't know if it is using compression or something, but I'll figure it out.

So for 2.4.4, the filter only works if you have installed Material Skin manually.

I'll see if I can handle both cases

Different paths I could understand.

OK, I discovered that the official version uses different resource names, e.g. toolbar.min.js versus toolbar.js, so now I have this working with the minify version.

Wouldn't it be easier not to use different resource names instead? Sounds like problems in the making.

[rgdawson]

Yes. Call me lazy.



Different paths I could understand.



Wouldn't it be easier not to use different resource names instead? Sounds like problems in the making.

It is common to apply Minification to production JavaScript and CSS code. Minification removes unnecessary or redundant data without affecting how the resource is processed by the browser - e.g. code comments and formatting, removing unused code, using shorter variable and function names, and so on. The server has to send all this code in text form to the browser, so minification improves performance. On the other hand the resulting code after minification is not what you want to work with when you are reading/modifying the code. So I think the way Craig does it with Material Skin is perfectly correct. He runs his code through the minfy process and the result are the same files with .min included in the name.

The Material Skin filter in SLX is just watching for when the browser requests specific .js and .css files. When it does, SLX just provides modified versions instead. So this is an easy fix in SLX to handle either naming convention, minified or not.

R Greg Dawson

[rgdawson]

Version 2.4.5

Version 2.4.5 submitted to MS Store.

Changes:

• When picking a default player, the player list is sorted.
• Maybe a solution for dolodobendan's problem with SLX browser failure to load the web page.
• The experimental Material Skin filter will work with minified version of the Material Skin plugin, whereas before it would only work with non-minified version. The minified version is what you get when you use the official plugin installed via LMS settings. The un-minified version is what you get when you install manually from the GitHub source.

R Greg Dawson

[cpd73]

The biggest thing for me, however are the collapsable sections. Removing those is way better for me, since I mostly stream.

[ATTACH]28008[/ATTACH] [ATTACH]28010[/ATTACH]

I'm comming round to this idea. What I'm thinking is to have a list similar to the above, but to also allow pinning items from 'My Music' - which would give me direct access to Artists, etc. I'll give this some thought for the next release...

[rgdawson]

I'm comming round to this idea. What I'm thinking is to have a list similar to the above, but to also allow pinning items from 'My Music' - which would give me direct access to Artists, etc. I'll give this some thought for the next release...

Outstanding! I think removing collapsible sections will make the home page more predictable and easy to navigate. Then, with the home page becoming essentially a single list, it might also afford you the opportunity to allow the user to drag and customize the order of things on the home page, like you do within Favorites. That way, for example, if the user pins Artists to the home page, the user could order Artists at the top or, say, below My Music, depending on the user's preference.

Once you go this route, you also might no longer need the option as to whether to use My Music categories from server (On/Off) anymore, so that would simplify things, too.

Love your work! Thanks, much!

R Greg Dawson

[dolodobendan]

It is common to apply Minification to production JavaScript and CSS code. Minification removes unnecessary or redundant data without affecting how the resource is processed by the browser - e.g. code comments and formatting, removing unused code, using shorter variable and function names, and so on. The server has to send all this code in text form to the browser, so minification improves performance. On the other hand the resulting code after minification is not what you want to work with when you are reading/modifying the code. So I think the way Craig does it with Material Skin is perfectly correct. He runs his code through the minfy process and the result are the same files with .min included in the name.

The Material Skin filter in SLX is just watching for when the browser requests specific .js and .css files. When it does, SLX just provides modified versions instead. So this is an easy fix in SLX to handle either naming convention, minified or not.

R Greg Dawson

Thank you for taking the time explaining this to me. Do I get it right that the .min.js files of the same resource may differ on different projects, as only used code is kept?

Version 2.4.5 submitted to MS Store.

Already here. (And, of course, MSF is working as expected now, thank you!)

allow pinning items from 'My Music' - which would give me direct access to Artists, etc. I'll give this some thought for the next release...

Please do, that sounds great!

[dolodobendan]

Once you go this route, you also might no longer need the option as to whether to use My Music categories from server (On/Off) anymore, so that would simplify things, too.

I'm not sure if this would work with Custom Browse's menus.

[rgdawson]

I'm not sure if this would work with Custom Browse's menus.

What I meant was Material Skin would always use server provided categories.

R Greg Dawson

[dolodobendan]

What I meant was Material Skin would always use server provided categories.

Ah. Phew!

[cpd73]

Outstanding! I think removing collapsible sections will make the home page more predictable and easy to navigate.

Checkout the 'devel' branch (this will be 1.0.0). Not sure how its more predictable, but still looks better (less cluttered).

Then, with the home page becoming essentially a single list, it might also afford you the opportunity to allow the user to drag and customize the order of things on the home page, like you do within Favorites. That way, for example, if the user pins Artists to the home page, the user could order Artists at the top or, say, below My Music, depending on the user's preference.

Yeah, currently pinned and the others are separate lists - but I'll see about combining them. Would make sense - and allow drag'n'drop re-ordering.

Once you go this route, you also might no longer need the option as to whether to use My Music categories from server (On/Off) anymore, so that would simplify things, too.

Already done :-)

Also, I guess further discussion of this should be in the Material thread - so as to not pollute this thread.

[rgdawson]

Checkout the 'devel' branch (this will be 1.0.0). Not sure how its more predictable, but still looks better (less cluttered).

I checked it out and it is great. By "predictable", I mean the locations of things are more stable, so the user can predict/expect where things will be.

Also, I guess further discussion of this should be in the Material thread - so as to not pollute this thread.

Yep, we are done here. Further discussion will be over on the Material thread.

R Greg Dawson