Making Services external extensions

[Aylur]

There was a question on the Discord server about why there are builtin services. There is also #107
How about removing the builtin services and instead let users pick services by having them in a single js file which they can import from. This would also allow for tweaking them

[kotontrion]

I would prefer a enableService option over a disableService option, because I think it's better to select the services you need instead of deselecting those you don't want.

[Aylur]

makes sense, added this as a vote option

[Aylur]

damn, didn't read the notice about it removing votes, whoops

[Frontear]

If possibly I would advocate instead for a conditional import, where it logs failure to run, but doesnt require explicit disabling enabling from the user.

If that isnt possible, then I think the best thing would be to explicitly enable which we use. Again though, I think the better solution was it tries import, if fails logs stderr, and just continues without making the service emit anything, thereby making it useless.

EDIT: Do you think you could clarify the behaviour of importing them from singular js files, and how that would be different from doing import Bluetooth from "resource:///.../bluetooth.js";?

[Aylur]

import Bluetooth from "resource:///.../bluetooth.js"; imports the module from the compiled resource which is located wherever it was installed
If we were to move services out of the source code, you would copy a js file and put it inside ~/.config/ags/services/bluetooth.js for example.
Then you would import it as any other local module with import Bluetooth from "./bluetooth.js";

[Aylur]

I thought about how enable/disable service config option would work and currently there would be a cyclic import because of the ags global variable so it's not possible.
So instead of having an enable/disable service option, the best solution here is to get rid of the ags global variable, and instead import the services only from the config, which is already working, the global variable is only there for convenience. This would mean that the libraries they depend on won't get loaded unnecessarily.

[Frontear]

If I understand what you're saying, you're saying that the const {} = ags. will no longer work, and instead we'd need to do import {} from "resource:///"?

[Aylur]

yes

[Frontear]

seems good, id consider this a perfectly viable solution. it would be nice to add a documentation entry with each import for reference so that it becomes a copy-paste type thing