Remove electricblue, default to "default"

[egmontkob]

(Two or three issues in one ticket.)

The skin selector opens with "electricblue", a skin that we don't even ship with mc.

Amid recent changes to skin files, this one wasn't updated.

I don't think the online skin browser should present any skin that the runtime software doesn't ship. Let alone make it the default.

If the skin is of good quality, and we have the permissions from its author, then let's update it and ship with mc. But then it'll still have no reason to be the default.

Otherwise we should remove it from official mc skins homepage. It will still be available in its own repo, locateable and usable by our users. That's perfectly fine, not every great skin has to be upstreamed.

The skin selector should open with mc's default skin.

While at it, I don't see the rationale in grouping them by the number of colors. I think a simple alphabetical sorting, except with "default" at the top (as in mc's runtime skin selector) would be simpler and better.

[zyv]

I have left it in the repository because it was there as a built-in example in the original version of @phplego, which didn't take the skins from the mc repository. I liked how the skin looks and felt it would be a pity to throw it away.

Unfortunately, the original author apparently has no interest in developing it further:

alexk7110/mc-electricblue256-skin#3

I wish someone would finish it up and add it to mc, but I guess you won't have an interest in taking ownership of it. In which case, I'm fine with dropping it from here. It's a pity, but that's life.

[zyv]

While at it, I don't see the rationale in grouping them by the number of colors. I think a simple alphabetical sorting, except with "default" at the top (as in mc's runtime skin selector) would be simpler and better.

Is it really so? I find the grouping by colors helpful as long as we don't have filtering by colors. Defaulting as a default is certainly meaningful, and I'd be fine with that.

[egmontkob]

I find the grouping by colors helpful

IMO it just complicates the layout: having to have sections, into which "default" will no longer fit as per this refactoring.

Also, having anything under the section of "User Skins" requires you to run the skin selector locally, something that extremely few users (if any apart from us) will ever do.

It's also unclear to me whether "User Skins" would also have three sub-sections based on the number of colors, leading to 2x3 sections. The naming doesn't suggest so, in which case it's inconsistent. (I could try locally.)

Actual mc doesn't group per colors, nor by user vs. system skins. IMO there's no point in adding more features to the skin viewer's dropdown list than to main mc's.

[phplego]

I have left it in the repository because it was there as a built-in example in the original version of @phplego

It was very long time ago when it wasn't a part of the mc website, so I think now it's better to align with the built in/shipped skins for simplicity

[zyv]

I find the grouping by colors helpful

IMO it just complicates the layout: having to have sections, into which "default" will no longer fit as per this refactoring.

I'd be more than happy with a flat Select2-based listing with the default skin selected if you would add checkboxes for dynamic filters instead, like this:

• 16 Colors
• 256 Colors
• True Color

I'd really like to see which skins have which colors and only consider skins that belong to one group. The groups are currently fulfilling this for me for the lack of filters.

Also, having anything under the section of "User Skins" requires you to run the skin selector locally, something that extremely few users (if any apart from us) will ever do.

Oh, this reminds me of the second reason why I kept the skin in the repository. I wanted to be able to do meaningful work on the editor just by checking it out.

I also didn't want to copy all skins from the main repository and keep them in sync. You know now how I solved this problem.

In theory, I could accept that if you checkout the editor locally and want to work on it, you simply must copy in some skin to do that, but that's really annoying.

However, if you are going to go as far as add a build system, then, of course, download of the latest skins can be added to an npm ci hook.

It's also unclear to me whether "User Skins" would also have three sub-sections based on the number of colors, leading to 2x3 sections. The naming doesn't suggest so, in which case it's inconsistent. (I could try locally.)

Of course not, and no, I don't think it's inconsistent. It's just that the name "users skins" is stupid; maybe it should have been something like "local skins" or "extra skins" instead. What I meant by that was "skin editor developer's skins shipped by default as an example so that you can work on the project directly after checking out the repository".

Actual mc doesn't group per colors, nor by user vs. system skins. IMO there's no point in adding more features to the skin viewer's dropdown list than to main mc's.

See above. Actually, I would have liked mc to also offer filters by colors, or group the skins for the lack of filters :)

[phplego]

Maybe we should commit all std skins to this repo also? To keep it simple.

[zyv]

Maybe we should commit all std skins to this repo also? To keep it simple.

To that, I would rather prefer to copy the skins in upon checkout.

[egmontkob]

Unfortunately, the original author apparently has no interest in developing it further: [...]

I wish someone would finish it up and add it to mc, but I guess you won't have an interest in taking ownership of it. In which case, I'm fine with dropping it from here. It's a pity, but that's life.

The original author did not respond, for whatever reason.

I kinda like this skin, it's quite different from the ones we have. The outdated bits could probably easily be updated, just as I did batch-update a bunch of skins when the skin engine changed.

License-wise the project is GPL so we're allowed to include it. Yet, I'm not sure if this would be a polite move without the author's explicit approval.

[zyv]

I'd just drop a comment in alexk7110/mc-electricblue256-skin#3 and remove it if he comes back to life and vehemently disapproves one day, which hopefully won't be the case.