Spices - how to share settings between all instances?

[matther]

Hi,

I'm writing a spice to control sct. Just click on the icon and take the next colorStep defined in the applet settings. You can use up to 7 steps.
It works fine if there is only one instance of that applet. But would be nice to have one instance per screen.
Thats easy you might say, just bind your settings like so:

Code: Select all

this.settings = new Settings.AppletSettings(this, metadata.uuid, instance_id)
this.settings.bind("colorStep1", "colorStep1")

But that means that every applet has its own configuration.

sct sets the screen color temperature for all screens at once. So the applet should share their configuration.
Instead of saving the at settings[uuid][instance_id] it would be nice to use global settings in that way:

Code: Select all

this.settings = new Settings.AppletSettings(this, metadata.uuid)

Or mark fields in settings-schema.json as global or shared to bind them to all instances.
Would be nice, but I haven't found a way to share the settings.

It might be possible by bad hacking, not using the binding, use my own settings object and build callbacks to sync them to the other instances...

Do you know a way to share settings between instances, use one settings collection for all instances?

[Drugwash]

Just an idea off the top of my head: use a single Python script as a custom module in your settings-schema.json, build your settings widget through it, and let it load/save a unique configuration file in a path of your own choice. It may look like a hack, but then again in Linux many things do. I know I had to perform my own hacks when the system was simply uncooperative.

You may wanna check out Applet PYE, my mod of Brightness and Gamma Applet, and maybe the others too. That one and Betterlock Plus use Python scripts for their Settings dialogs.

[matther]

I've seen the python scripts, but havn't digged into it yet.

At some moments I think the "every applet is on its own" thing is some common sense fixed in a style guide. But there is no clue that there is any. And perhaps the API is simply not implemented.

Thanks for the hint. I'll have a look.

[Drugwash]

Spices development is somehow chaotic in my personal opinion, as there is no specialized framework/tool/whatever to guide developers, no IDE. Sure, there is some documentation for a few pieces of the "puzzle" - the -doc packages installable through Synaptic or at command line, and then available in Devhelp - but they are incomplete and in some cases nonfunctional (some old Python docs wouldn't show up in Devhelp), and on top of that there are almost no practical examples as to how to use the various API, other than peeking through other Spices in the repository and/or combing the main Cinnamon sources looking for clues. Which is extremely time-consuming and frustrating.

By the way, if you're the developer for the SCT Toggle applet you may wanna double-check the package that is being delivered from the repository. Earlier on I just got notified about some language update and upon updating the applet got broken; main file (applet.js) was missing all command terminators (the semicolons) and there was a stray question mark in some function call. Not sure if it was a network error, never happened before.

[matther]

Yes, I am the developer of the sct toggle.

The semicolons should not be a problem. They are optional on most places in js. I think omitting them removes some visual clutter. In my daily work I see less semicolons from year to year.
My first version was merged some days ago with translations for en and de. Someone else added es. And some hours ago I commited a new new version with fr and it.
I take a look for the question mark and home that it is already fixed with the last version.

[Drugwash]

First version was OK, I had it installed and it worked (in Mint 19.2). The recent one had the problem.

I'm not that familiar with the JS syntax, did notice the missing semicolons here and there in a few Spices but didn't know they would be optional. Personally I stick to the "old ways" just to be on the safe side. It does get a bit blurry when switching between JS and Python, and occasionally to AHK. Maybe I'm just getting too old (for this... - you may know the line in the Lethal Weapon franchise )

[matther]

Did you mean the line

Code: Select all

this.settings?.getValue("currentStep")

That is optional chaining which is realy nice. Think about anObject.with.many.optional.childs and one of them is undefined. Before optional chaining it was neccessary to
if (anObject && anObject.with && anObject.width.many...) before accessing the element, or you get an "cannot access childs of undefined" error. But now it returns childs or undefined. Makes the world easier.

So, yes, this question mark should be there.

You said Mint 19.2 which was published in 2019. https://caniuse.com/?search=%3F. says that the optional chaining is in firefox (and the others) since 2020. So I guess your mint is a way older than that syntax. The support for 19.2 did end april last year. Perhaps its time for an update.

Did not thought that this is still relevant yet. I can fix that.

[Drugwash]

Yep, that was it. So it wasn't a bug or a network error - just an updated syntax that my system can't handle. Good news...for the updated users.

Problem is, everything after 19.2 went downhill strictly from my point of view. May seem minor but we all have things we get attached to, and when they go away for whatever reason we don't feel good. If a change is not absolutely compulsory one will choose to stick to whatever looks and works as they want - no compromises needed.

Besides, my machine - a Samsung NP-R580 notebook - is a 2009 model, built in 2010 with just small upgrades: an i5 CPU instead of the default i3, and 8GB of DDR3 instead of the 4GB it came with. Bought second-hand because couldn't afford a new one (and now definitely not). It might have certain difficulties adjusting to a recent OS version.

So, that's it. I'm happy with whatever works, fix/modify whatever possible, and enjoy whatever I can.

You could wrap that line in a try/catch, it may be easier than maintaining separate scripts for multiple Cinnamon versions.

EDIT: When it comes to backward compatibility, for the future you could check out this table.

[matther]

Code: Select all

let currentStep = 0
if (this.settings && this.settings.getValue("currentStep")) {
    currentStep = this.settings.getValue("currentStep")
}

instead of

Code: Select all

let currentStep = this.settings?.getValue("currentStep") || 0

Its only 3 lines more and 1 occurrence in the code.

I have heart that everything we get to know in the first 20 years is like it must be. Things invented when you were 20-40 is cool new stuff. And things which got invented when you were older is unnecessary stuff from hell. For every generation. The actual years vary from person to person.

I have had opened another thread, dealing with icon colors. Do you have any idea on that topic?

[Drugwash]

If this.settings wouldn't exist that would be a major issue with the system, so maybe that check could be skipped.
You could initialize currentStep to zero by default within settings-schema.json so you'd be sure it's initialized at first start after installation. If it ever were to be missing then the whole settings file would be missing, and again that would be a problem in the system (or a screw-up on user's part).
When it gets modified it will be saved automatically, and loaded at next start. That would avoid the extra check(s) - unless you wanna be very strict about it.

Haven't seen the new topic, will check it out. Not sure if I can be of any help though if it's about colorizing "modern" (symbolic) icons - I have those disabled overall since day one, can't stand that hieroglyphic approach to computing.

[matther]

You are right, that check can get deleted. When exploring how the settings work and where the documentation is up to date and where not, I tried different approaches. Using the this.settings.bind and the default to 0 will be enough.

I like one check more, in general. JS is nicely weak typed, so better take a closer look to the object.

And the icons. I like the symbolic ones. Yes its hieroglyphic. My daughter knows the symbol to save and have never seen a 3,5" floppy disk. More colored icons give some more clues to the meaning. But I know this language and monochromatic icons are less distractive. They are status icons in the background. If everything is ok, they are nearly invisible, only visible enough to see that they are there and fine and working. So are able to set a highlight if necessary. Give the PleaseUpdateButton a red dot saying: "User! Do Something." If the icons were colored by default that would be harder to add another attraction.
If the environment is unfamiliar to the user, its always better to write words instead of unknown icons.

[Drugwash]

A very strict language tends to become tiresome at some point. I had major difficulties with Python in the beginning due to its strict indentation requirement. I'm used to quick improvisations, trial and error, nevermind the aspect of the code - that can be fixed later on when everything just works. Python doesn't allow such behavior, and that hinders me a lot. Guess we each have our own coding style and paradigms.

Symbolic icons may be easy on the eyes for young people and/or with good eyesight. For those of us that are neither too young nor too sharp-sighted they are a major drag. Colors and complex shapes help very much in distinguishing icons - and thus functions - from one-another. That's why I prefer nicely colored and shaped icons. Tray icons could use some easy-to-implement native animation when notifications are urgent. Windows had it right long ago (see the POP Peeper tray icon when new mail is in).

Here's how my main panel looks like in Mint 19.2; there still are 3 or 4 symbolic icons (to the right), never got around to replacing them:

[Drugwash]

Here's how I modified the main applet script:

applet.js

(3.09 KiB) Downloaded 20 times

settings-schema.zip

(607 Bytes) Downloaded 23 times

Isn't it ironic: can attach js file, can't attach .json file. Ha!

As it is now, if you ever decide to change the number of available values in settings just add/remove the corresponding colorStepN entries and modify the value of maxSteps accordingly. The main script should not need any adjustment whatsoever in this regard.

Hope it still works in newest Cinnamon 6.x - it sure does here in Mint 19.2 / Cinnamon 4.2.4.

[matther]

Thanks for your suggestions. I keep some of them, but discard other.
Keeping the temperature typo fix and the maxSteps.
The temperature is a numberish value, but will be given to sct as a string. So the parseInt and the conversion isn't necessary. "someString"+someInt gets concated to an string with an implicit convertion from int to string. So the temperature.toString() isn't required.
I am of two minds about the tenary operator. You added on in the getNextStep function. It shortens the code, but sometimes it become too dense to understand it easily for me. Some

Code: Select all

let price = isMember ? '$2.00' : '$10.00'

is short and would be ok, but

Code: Select all

this.currentStep = (this.currentStep >= (stepsLength -1)) ? 0 : this.currentStep + 1;

is not.

[Drugwash]

Hey, no worries, it's your code, do as you feel right. I'm always playing with new code when I feel like it but at the end of the day it's just my vision, and doesn't always fit anybody else's. It's fun though.

Good luck ahead!