Skin Module Bug? Or Feature request.

Post Reply
tgrey
Posts: 122
Joined: Sat Apr 03, 2021 8:39 pm

Skin Module Bug? Or Feature request.

Post by tgrey » Thu Sep 23, 2021 10:57 am

If you set a theme using the skin module and then delete it... the next time you add the skin module to a patch it resets back to the default. I was just hoping to make a small change it due to a lower screen brightness at night, I didn't want a full reset!

I think it would be great if the skin module loaded the saved skin first so that it could be tweaked.

ColinP
Posts: 227
Joined: Mon Aug 03, 2020 7:46 pm

Re: Skin Module Bug? Or Feature request.

Post by ColinP » Thu Sep 23, 2021 3:48 pm

The idea here is that you can have just one skin for all projects or that different projects can have different skins, so that's why things work the way they do.

But I can see your point that if you load a new Skin module into a patch that didn't have one before then it should initialize to the settings of the last patch that ran rather than the default settings.

I'll see if I can implement this as your suggestion is a good one. Thanks!

tgrey
Posts: 122
Joined: Sat Apr 03, 2021 8:39 pm

Re: Skin Module Bug? Or Feature request.

Post by tgrey » Thu Sep 23, 2021 7:37 pm

Oh, so the color settings save with each patch? I hadn't noticed or tried that yet! That is definitely a feature I wouldn't want to interfere with... but yes, it would be great if both could happen without creating too much trouble for users (or developers! :D )

Thanks for considering it, I hope to see it added.

ColinP
Posts: 227
Joined: Mon Aug 03, 2020 7:46 pm

Re: Skin Module Bug? Or Feature request.

Post by ColinP » Thu Sep 23, 2021 11:15 pm

The settings are saved with each instance of a Skin module but also in a global property. So if a patch contains a Skin module then its settings are used and then become the global property.

The idea is that you might be working on two or more projects simultaneously that look very similar and by having a Skin module as part of the patch you can use color coding so that it's obvious which version you are currently editing.

On the other hand you might not need this facility so can load up a Skin module once to set your preference and then delete it to save space.

What I'm going to try and do is have different behaviour for a Skin module's initialization depending on whether it's part of a patch when the patch is loaded or whether it's added later. In the former case it will behave as now, in the latter case it'll load the global property if that exists.

It's tricky though due to the way modules initialise but I think I can sort it by suppressing certain events for a short period if the uptime is greater than one second say. I'll look at this tomorrow and post an update here.

ColinP
Posts: 227
Joined: Mon Aug 03, 2020 7:46 pm

Re: Skin Module Bug? Or Feature request.

Post by ColinP » Fri Sep 24, 2021 1:23 pm

OK, I've had a good look at this and while I can determine what time VM loads and what time a module loads, I can't determine what time a preset loads. I had hoped that I'd be able to determine this from the Preset_Loading_Finish event but unfortunately VM sends this event whenever a module loads rather than just when a preset loads.

So the only way I can think to determine if a Skin module was loaded as part of a preset or is being freshly added is to make all LSSP modules other than Skin write a timestamp property when they finish initializing. Then Skin could calculate how "old" it is relative to the other modules in the patch and modify its behaviour accordingly.

Unfortunately this requires every single LSSP module to be modified and reapproved so I'm going to defer this mod until there's a need to do that for other reasons - such as a new version of the Skin module with more powerful features.

Post Reply