Preloaded addons

PPPDUD commented

2026-04-19 17:03:19 -05:00

(Migrated from github.com)

As part of my goal to rewrite Jameson as a series of Sparkle addons and Sparkle as a series of Jameson components, I need a way to add preloaded addons: addons which a fork loads at startup and which can be enabled/disabled but not removed.

What follows is my idea for how this should be done.

API layout

In the lines immediately after <script src="src/sparkle.js"></script>, the fork would place this code, where src/addon.js is the relative path of a preloaded addon:

<script>
waitForSnapReady().then(preloadAddonFromPath("src/addon.js"));
</script>

This code will wait for the fork to fully initialize, and then instruct Sparkle to load the addon. If the addon has been disabled, this will fail silently with no errors.

(Before anyone asks, don't worry, I've already made waitForSnapReady() available to forks in acd7191.)

UI/UX aspects

Whenever the user opens the list of addons and a premade addon's displayed, the following aspects will be changed:

the delete button will become an enable/disable button; if the addon's state is changed, the user will be shown a warning message telling them that they need to reload for the action to take effect
the autoload button is not shown, even in developer mode

@Mojavesoft-Group/sparkle-team Anybody up to the task?

As part of my goal to rewrite Jameson as a series of Sparkle addons and Sparkle as a series of Jameson components, I need a way to add _preloaded addons_: addons which a fork loads at startup and which can be enabled/disabled but not removed. What follows is my idea for how this should be done. ## API layout In the lines immediately after `<script src="src/sparkle.js"></script>`, the fork would place this code, where `src/addon.js` is the relative path of a preloaded addon: ~~~html <script> waitForSnapReady().then(preloadAddonFromPath("src/addon.js")); </script> ~~~ This code will wait for the fork to fully initialize, and then instruct Sparkle to load the addon. If the addon has been disabled, this will fail silently with no errors. (Before anyone asks, don't worry, I've already made `waitForSnapReady()` available to forks in acd7191.) ## UI/UX aspects Whenever the user opens the list of addons and a premade addon's displayed, the following aspects will be changed: - the delete button will become an enable/disable button; if the addon's state is changed, the user will be shown a warning message telling them that they need to reload for the action to take effect - the autoload button is not shown, even in developer mode @Mojavesoft-Group/sparkle-team Anybody up to the task?

PPPDUD commented

2026-04-19 17:08:23 -05:00

(Migrated from github.com)

Please direct all development for this issue to the preloaded-addons branch.

Please direct all development for this issue to the `preloaded-addons` branch.

e016 commented

2026-04-20 10:06:40 -05:00

(Migrated from github.com)

I think a "disable/enable" button would also work well with user-downloaded addons (temporarily remove addon, but turn it on later)

👍 1

PPPDUD commented

2026-04-20 10:08:10 -05:00

(Migrated from github.com)

I think a "disable/enable" button would also work well with user-downloaded addons (temporarily remove addon, but turn it on later)

Agreed.

> I think a "disable/enable" button would also work well with user-downloaded addons (temporarily remove addon, but turn it on later) Agreed.

e016 commented

2026-04-26 18:58:02 -05:00

(Migrated from github.com)

I've made an addon enabler/disabler:

It automatically saves your addon disable preferences! Any concerns or changes needed?

I've made an addon enabler/disabler: <img width="583" height="165" alt="Image" src="https://github.com/user-attachments/assets/ddbb6922-9902-4403-9f0a-cc6d24ba5899" /> It automatically saves your addon disable preferences! Any concerns or changes needed?

PPPDUD commented

2026-04-26 19:07:39 -05:00

(Migrated from github.com)

I've made an addon enabler/disabler:
It automatically saves your addon disable preferences! Any concerns or changes needed?

I love it! I don't like the slash icon though, can you make the dropdown arrow larger and use that instead?

> I've made an addon enabler/disabler: > > <img alt="Image" width="583" height="165" src="https://private-user-images.githubusercontent.com/244850916/583928636-ddbb6922-9902-4403-9f0a-cc6d24ba5899.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzcyNDg2ODQsIm5iZiI6MTc3NzI0ODM4NCwicGF0aCI6Ii8yNDQ4NTA5MTYvNTgzOTI4NjM2LWRkYmI2OTIyLTk5MDItNDQwMy05ZjBhLWNjNmQyNGJhNTg5OS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyN1QwMDA2MjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03OTdmNTg1NzI1YWE2MGY1Mzk3ZjI3NWQ1Y2Q2NjNhMGY0YTE3ZTlhMTJlMjYxZDdhNGRhNDA4MzdkMWM4MWNhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.ANVMYi8-qx41C41npOWYe5KA_OLv_Kkw0PA6rIP2dpo"> > It automatically saves your addon disable preferences! Any concerns or changes needed? I love it! I don't like the slash icon though, can you make the dropdown arrow larger and use that instead?

e016 commented

2026-04-26 19:13:37 -05:00

(Migrated from github.com)

I've made an addon enabler/disabler:

It automatically saves your addon disable preferences! Any concerns or changes needed?

I love it! I don't like the slash icon though, can you make the dropdown arrow larger and use that instead?

I think a better way would be a tick box at the left of the text, that way it doesn't interfere with the delete button

> > I've made an addon enabler/disabler: > > <img alt="Image" width="583" height="165" src="https://private-user-images.githubusercontent.com/244850916/583928636-ddbb6922-9902-4403-9f0a-cc6d24ba5899.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzcyNDg2ODQsIm5iZiI6MTc3NzI0ODM4NCwicGF0aCI6Ii8yNDQ4NTA5MTYvNTgzOTI4NjM2LWRkYmI2OTIyLTk5MDItNDQwMy05ZjBhLWNjNmQyNGJhNTg5OS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyN1QwMDA2MjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03OTdmNTg1NzI1YWE2MGY1Mzk3ZjI3NWQ1Y2Q2NjNhMGY0YTE3ZTlhMTJlMjYxZDdhNGRhNDA4MzdkMWM4MWNhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.ANVMYi8-qx41C41npOWYe5KA_OLv_Kkw0PA6rIP2dpo"> > > It automatically saves your addon disable preferences! Any concerns or changes needed? > > I love it! I don't like the slash icon though, can you make the dropdown arrow larger and use that instead? I think a better way would be a tick box at the left of the text, that way it doesn't interfere with the delete button

codingisfun2831t commented

2026-04-26 20:24:56 -05:00

(Migrated from github.com)

Real quick, I think implementing a "ModDisplayerMorph" is good
Basically its a morph, that takes in a object- either a Mod which is currently loaded, or the info object for a addon from the repo.
It would handle both of them, and allow viewing info, changelogs, etc etc you know the drill.

Real quick, I think implementing a "ModDisplayerMorph" is good Basically its a morph, that takes in a object- either a Mod which is currently loaded, or the info object for a addon from the repo. It would handle both of them, and allow viewing info, changelogs, etc etc you know the drill.

e016 commented

2026-04-26 20:28:35 -05:00

(Migrated from github.com)

Should I commit this? Or is there anything else to change?

<img width="671" height="171" alt="Image" src="https://github.com/user-attachments/assets/06f3c447-3b19-4d6e-9ab1-3753d2f6f277" /> Should I commit this? Or is there anything else to change?

PPPDUD commented

2026-04-27 07:12:47 -05:00

(Migrated from github.com)

Should I commit this? Or is there anything else to change?

Looks good to me, would you please commit to the preloaded-addons branch though? That way, the master branch won't be half-broken while this feature is being developed.

> <img alt="Image" width="671" height="171" src="https://private-user-images.githubusercontent.com/244850916/583939435-06f3c447-3b19-4d6e-9ab1-3753d2f6f277.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzcyOTIxNTAsIm5iZiI6MTc3NzI5MTg1MCwicGF0aCI6Ii8yNDQ4NTA5MTYvNTgzOTM5NDM1LTA2ZjNjNDQ3LTNiMTktNGQ2ZS05YWIxLTM3NTNkMmY2ZjI3Ny5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyN1QxMjEwNTBaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1jZWVkMjRkZmNkMDFjODc4ODk2NWNiNzA2ZWY5YmRhZWMwYjQxMGE3MzFjNWFmYTAyOTMxNWE3ZWUyNTYyZjZmJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.s0S3_QHdeBClL6h5jf18nzLb66E3dSOv03WWpEOkH9U"> > Should I commit this? Or is there anything else to change? Looks good to me, would you please commit to the preloaded-addons branch though? That way, the master branch won't be half-broken while this feature is being developed.

e016 commented

2026-04-27 09:49:08 -05:00

(Migrated from github.com)

Should I commit this? Or is there anything else to change?

Looks good to me, would you please commit to the preloaded-addons branch though? That way, the master branch won't be half-broken while this feature is being developed.

I'll do that, although this is just the enable/disable, nothing else.

> > <img alt="Image" width="671" height="171" src="https://private-user-images.githubusercontent.com/244850916/583939435-06f3c447-3b19-4d6e-9ab1-3753d2f6f277.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzcyOTIxNTAsIm5iZiI6MTc3NzI5MTg1MCwicGF0aCI6Ii8yNDQ4NTA5MTYvNTgzOTM5NDM1LTA2ZjNjNDQ3LTNiMTktNGQ2ZS05YWIxLTM3NTNkMmY2ZjI3Ny5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyN1QxMjEwNTBaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1jZWVkMjRkZmNkMDFjODc4ODk2NWNiNzA2ZWY5YmRhZWMwYjQxMGE3MzFjNWFmYTAyOTMxNWE3ZWUyNTYyZjZmJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.s0S3_QHdeBClL6h5jf18nzLb66E3dSOv03WWpEOkH9U"> > > Should I commit this? Or is there anything else to change? > > Looks good to me, would you please commit to the preloaded-addons branch though? That way, the master branch won't be half-broken while this feature is being developed. I'll do that, although this is just the enable/disable, nothing else.

👍 1

e016 commented

2026-04-27 11:02:38 -05:00

(Migrated from github.com)

I've added the enable/disable in the preloaded-addons branch!

I am mostly on board with the whole Sparkle-replacing-Snap-mods thing (the mod developer just has to make lots of addons instead of modding snap source code), so I'll continue with the preloaded stuff

<img width="356" height="136" alt="Image" src="https://github.com/user-attachments/assets/67444b92-3fd7-41ae-b0f8-94a9efff90bd" /> I've added the enable/disable in the preloaded-addons branch! I am _mostly_ on board with the whole Sparkle-replacing-Snap-mods thing (the mod developer just has to make lots of addons instead of modding snap source code), so I'll continue with the preloaded stuff

🎉 1

PPPDUD commented

2026-04-27 11:04:08 -05:00

(Migrated from github.com)

I've added the enable/disable in the preloaded-addons branch!
I am mostly on board with the whole Sparkle-replacing-Snap-mods thing (the mod developer just has to make lots of addons instead of modding snap source code), so I'll continue with the preloaded stuff

Thanks so much! Great work.

> <img alt="Image" width="356" height="136" src="https://private-user-images.githubusercontent.com/244850916/584316249-67444b92-3fd7-41ae-b0f8-94a9efff90bd.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzczMDYxMjYsIm5iZiI6MTc3NzMwNTgyNiwicGF0aCI6Ii8yNDQ4NTA5MTYvNTg0MzE2MjQ5LTY3NDQ0YjkyLTNmZDctNDFhZS1iMGY4LTk0YTllZmZmOTBiZC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyN1QxNjAzNDZaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zNDEzNzliNGZlY2U5ZmY1ZDQxNWViZmIxN2E4N2FhOTkwN2Y2YmJkZTU3NTVhNzhiNDUzN2MzYzJmZjM5Mjc3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.iGTloFUme1FIQa68jiOC-0WFI1VsJbU95e4J-4E9ylw"> > I've added the enable/disable in the preloaded-addons branch! > > I am _mostly_ on board with the whole Sparkle-replacing-Snap-mods thing (the mod developer just has to make lots of addons instead of modding snap source code), so I'll continue with the preloaded stuff Thanks so much! Great work.

PPPDUD commented

2026-04-27 11:05:17 -05:00

(Migrated from github.com)

@e016 One little tidbit though: I changed the button colors in the main branch to make them look a bit less jarring, would you please copy those changes over to preloaded-addons too?

@e016 One little tidbit though: I changed the button colors in the main branch to make them look a bit less jarring, would you please copy those changes over to `preloaded-addons` too?

codingisfun2831t commented

2026-04-27 16:53:03 -05:00

(Migrated from github.com)

I don't know if this is on topic, but the only issue in my eyes with the mod-replacing-forks thing is.. compatiblity. For something like Split!, that modifies Snap! a whole darn lot. That could provide incompatibilly with other mods.

And, just like some other stuff, I've grown to like the idea. The idea of being able to simply just load a mod and get the blocks of Split!, or get the extra features of Snavanced, etc etc. Now the issue is, we don't want users to just create projects needing all of that randomly. We already know people don't like enabling JS for projects. Now how this could work is of course is that we could partner up with the Snap! team (that's probably not happening, though) and have a system for that to redirect projects to the correct mods.

I don't know if this is on topic, but the only issue in my eyes with the mod-replacing-forks thing is.. compatiblity. For something like Split!, that modifies Snap! a whole darn lot. That could provide incompatibilly with other mods. And, just like some other stuff, I've grown to like the idea. The idea of being able to simply just load a mod and get the blocks of Split!, or get the extra features of Snavanced, etc etc. Now the issue is, we don't want users to just create projects needing all of that randomly. We already know people don't like enabling JS for projects. Now how this could work is of course is that we could partner up with the Snap! team (that's probably not happening, though) and have a system for that to redirect projects to the correct mods.

PPPDUD commented

2026-04-27 16:54:44 -05:00

(Migrated from github.com)

I don't know if this is on topic, but the only issue in my eyes with the mod-replacing-forks thing is.. compatiblity. For something like Split!, that modifies Snap! a whole darn lot. That could provide incompatibilly with other mods.

And, just like some other stuff, I've grown to like the idea. The idea of being able to simply just load a mod and get the blocks of Split!, or get the extra features of Snavanced, etc etc. Now the issue is, we don't want users to just create projects needing all of that randomly. We already know people don't like enabling JS for projects. Now how this could work is of course is that we could partner up with the Snap! team (that's probably not happening, though) and have a system for that to redirect projects to the correct mods.

That's certainly one way to accomplish that task.

> I don't know if this is on topic, but the only issue in my eyes with the mod-replacing-forks thing is.. compatiblity. For something like Split!, that modifies Snap! a whole darn lot. That could provide incompatibilly with other mods. > > And, just like some other stuff, I've grown to like the idea. The idea of being able to simply just load a mod and get the blocks of Split!, or get the extra features of Snavanced, etc etc. Now the issue is, we don't want users to just create projects needing all of that randomly. We already know people don't like enabling JS for projects. Now how this could work is of course is that we could partner up with the Snap! team (that's probably not happening, though) and have a system for that to redirect projects to the correct mods. That's certainly one way to accomplish that task.

e016 commented

2026-04-27 17:38:11 -05:00

(Migrated from github.com)

I don't know if this is on topic, but the only issue in my eyes with the mod-replacing-forks thing is.. compatiblity. For something like Split!, that modifies Snap! a whole darn lot. That could provide incompatibilly with other mods.
And, just like some other stuff, I've grown to like the idea. The idea of being able to simply just load a mod and get the blocks of Split!, or get the extra features of Snavanced, etc etc. Now the issue is, we don't want users to just create projects needing all of that randomly. We already know people don't like enabling JS for projects. Now how this could work is of course is that we could partner up with the Snap! team (that's probably not happening, though) and have a system for that to redirect projects to the correct mods.

That's certainly one way to accomplish that task.

I think we might be able to embed metadata about sparkle addons (e.g: uses split or jameson addons) and have Sparkle recommend those addons

> > I don't know if this is on topic, but the only issue in my eyes with the mod-replacing-forks thing is.. compatiblity. For something like Split!, that modifies Snap! a whole darn lot. That could provide incompatibilly with other mods. > > And, just like some other stuff, I've grown to like the idea. The idea of being able to simply just load a mod and get the blocks of Split!, or get the extra features of Snavanced, etc etc. Now the issue is, we don't want users to just create projects needing all of that randomly. We already know people don't like enabling JS for projects. Now how this could work is of course is that we could partner up with the Snap! team (that's probably not happening, though) and have a system for that to redirect projects to the correct mods. > > That's certainly one way to accomplish that task. I think we might be able to embed metadata about sparkle addons (e.g: uses split or jameson addons) and have Sparkle recommend those addons

PPPDUD commented

2026-04-27 17:41:22 -05:00

(Migrated from github.com)

I don't know if this is on topic, but the only issue in my eyes with the mod-replacing-forks thing is.. compatiblity. For something like Split!, that modifies Snap! a whole darn lot. That could provide incompatibilly with other mods.
And, just like some other stuff, I've grown to like the idea. The idea of being able to simply just load a mod and get the blocks of Split!, or get the extra features of Snavanced, etc etc. Now the issue is, we don't want users to just create projects needing all of that randomly. We already know people don't like enabling JS for projects. Now how this could work is of course is that we could partner up with the Snap! team (that's probably not happening, though) and have a system for that to redirect projects to the correct mods.

That's certainly one way to accomplish that task.

I think we might be able to embed metadata about sparkle addons (e.g: uses split or jameson addons) and have Sparkle recommend those addons

Sure, but wouldn't that be pushing Sparkle's feature set a bit too far? My philosophy is that Sparkle should be an integratable addons manager with a few addon-facing APIs and nothing else. All other functionality is to be accomplished by addons and Snap! or one of its forks.

> > > I don't know if this is on topic, but the only issue in my eyes with the mod-replacing-forks thing is.. compatiblity. For something like Split!, that modifies Snap! a whole darn lot. That could provide incompatibilly with other mods. > > > And, just like some other stuff, I've grown to like the idea. The idea of being able to simply just load a mod and get the blocks of Split!, or get the extra features of Snavanced, etc etc. Now the issue is, we don't want users to just create projects needing all of that randomly. We already know people don't like enabling JS for projects. Now how this could work is of course is that we could partner up with the Snap! team (that's probably not happening, though) and have a system for that to redirect projects to the correct mods. > > > > > > That's certainly one way to accomplish that task. > > I think we might be able to embed metadata about sparkle addons (e.g: uses split or jameson addons) and have Sparkle recommend those addons Sure, but wouldn't that be pushing Sparkle's feature set a bit too far? My philosophy is that Sparkle should be an integratable addons manager with a few addon-facing APIs and nothing else. All other functionality is to be accomplished by addons and Snap! or one of its forks.

codingisfun2831t commented

2026-04-28 14:11:11 -05:00

(Migrated from github.com)

Idea: maybe for forks embedding Sparkle, we should make Sparkle more "module" nice, where you can include the sparkle JS file, and then run a SparkleSDK.init(opts) function with that kind of info, including preloaded icons. Then, for the extension, we can keep the sparkle code and add a extra initialization code to run that function.

PPPDUD commented

2026-04-28 14:15:21 -05:00

(Migrated from github.com)

Idea: maybe for forks embedding Sparkle, we should make Sparkle more "module" nice, where you can include the sparkle JS file, and then run a SparkleSDK.init(opts) function with that kind of info, including preloaded icons. Then, for the extension, we can keep the sparkle code and add a extra initialization code to run that function.

Are you proposing that both the integrated Sparkle and the Sparkle extension execute the same custom code? Wouldn't that cause a race condition?

> Idea: maybe for forks embedding Sparkle, we should make Sparkle more "module" nice, where you can include the sparkle JS file, and then run a SparkleSDK.init(opts) function with that kind of info, including preloaded icons. Then, for the extension, we can keep the sparkle code and add a extra initialization code to run that function. Are you proposing that both the integrated Sparkle and the Sparkle extension execute the same custom code? Wouldn't that cause a race condition?

codingisfun2831t commented

2026-04-28 14:17:29 -05:00

(Migrated from github.com)

No. I'm saying that the extension can do that if Sparkle isn't included in a fork, and for he forks that do include can customize Sparkle

PPPDUD commented

2026-04-28 14:20:40 -05:00

(Migrated from github.com)

No. I'm saying that the extension can do that if Sparkle isn't included in a fork, and for he forks that do include can customize Sparkle

Why would a fork contain metadata for Sparkle if it didn't already integrate it? It's not like integrating Sparkle is hard, it's just downloading a file and editing another.

> No. I'm saying that the extension can do that if Sparkle isn't included in a fork, and for he forks that do include can customize Sparkle Why would a fork contain metadata for Sparkle if it didn't already integrate it? It's not like integrating Sparkle is hard, it's just downloading a file and editing another.

codingisfun2831t commented

2026-04-28 14:22:47 -05:00

(Migrated from github.com)

As in, preloaded addons. The topic of this issue 😉

PPPDUD commented

2026-04-28 14:26:41 -05:00

(Migrated from github.com)

As in, preloaded addons. The topic of this issue 😉

I'm still really confused about what you mean. Are you proposing that the extension be used as a way of customizing an integrated Sparkle instance?

> As in, preloaded addons. The topic of this issue 😉 I'm still really confused about what you mean. Are you proposing that the extension be used as a way of customizing an integrated Sparkle instance?

codingisfun2831t commented

2026-04-28 14:30:59 -05:00

(Migrated from github.com)

Nononono.

There will be a single sparkle.js. That exports a object, SparkleSDK (basically __sparkle__). That has a function, main. You pass in a object with options to that function. Forks can do this for preloaded addons.

Then, the main sparkle extension of course still has sparkle.js, but includes a main.js right after (content scripts) that run that main function.

Nononono. There will be a single sparkle.js. That exports a object, SparkleSDK (basically `__sparkle__`). That has a function, main. You pass in a object with options to that function. Forks can do this for preloaded addons. Then, the main sparkle extension of course still has sparkle.js, but includes a main.js right after (content scripts) that run that main function.

PPPDUD commented

2026-04-28 14:33:03 -05:00

(Migrated from github.com)

Nononono.

There will be a single sparkle.js. That exports a object, SparkleSDK (basically __sparkle__). That has a function, main. You pass in a object with options to that function. Forks can do this for preloaded addons.

Then, the main sparkle extension of course still has sparkle.js, but includes a main.js right after (content scripts) that run that main function.

Are you proposing a system in which Sparkle itself is not included in the fork, but rather a piece of code for communicating with the Sparkle extension?

> Nononono. > > There will be a single sparkle.js. That exports a object, SparkleSDK (basically `__sparkle__`). That has a function, main. You pass in a object with options to that function. Forks can do this for preloaded addons. > > Then, the main sparkle extension of course still has sparkle.js, but includes a main.js right after (content scripts) that run that main function. Are you proposing a system in which Sparkle itself is not included in the fork, but rather a piece of code for communicating with the Sparkle extension?

codingisfun2831t commented

2026-04-28 14:37:10 -05:00

(Migrated from github.com)

No! The fork will have its own Sparkle, that it has a script tag a- like now, but it must have code to call main on it.

e016 commented

2026-04-28 14:38:59 -05:00

(Migrated from github.com)

No! The fork will have its own Sparkle, that it has a script tag a- like now, but it must have code to call main on it.

So you have to manually call main() if you're integrating Sparkle into a Snap! fork?

__crackle__.main({ 
  preloadedAddons: [
    // ...
  ]
})

> No! The fork will have its own Sparkle, that it has a script tag a- like now, but it must have code to call main on it. So you have to manually call main() if you're integrating Sparkle into a Snap! fork? ```js __crackle__.main({ preloadedAddons: [ // ... ] }) ```

PPPDUD commented

2026-04-28 14:39:52 -05:00

(Migrated from github.com)

No! The fork will have its own Sparkle, that it has a script tag a- like now, but it must have code to call main on it.

So the fork can activate Sparkle later on instead of starting it up at once?

> No! The fork will have its own Sparkle, that it has a script tag a- like now, but it must have code to call main on it. So the fork can activate Sparkle later on instead of starting it up at once?

codingisfun2831t commented

2026-04-28 14:39:55 -05:00

(Migrated from github.com)

Yeah, but with SparkleSDK of course

e016 commented

2026-04-28 14:41:11 -05:00

(Migrated from github.com)

No! The fork will have its own Sparkle, that it has a script tag a- like now, but it must have code to call main on it.

So the fork can activate Sparkle later on instead of starting it up at once?

Yes, and it also lets you pass an object as a parameter into main, letting you do things like

__crackle__.main({ 
  preloadedAddons: [
    // ...
  ]
})

> > No! The fork will have its own Sparkle, that it has a script tag a- like now, but it must have code to call main on it. > > So the fork can activate Sparkle later on instead of starting it up at once? Yes, and it also lets you pass an object as a parameter into main, letting you do things like > ```js > __crackle__.main({ > preloadedAddons: [ > // ... > ] > }) > ```

PPPDUD commented

2026-04-28 14:41:16 -05:00

(Migrated from github.com)

Yeah, but with SparkleSDK of course

By SparkleSDK, what do you mean exactly? We officially ditched the SDK branding when we moved to my organization.

> Yeah, but with SparkleSDK of course By SparkleSDK, what do you mean exactly? We officially ditched the SDK branding when we moved to my organization.

codingisfun2831t commented

2026-04-28 14:41:57 -05:00

(Migrated from github.com)

By SparkleSDK, what do you mean exactly? We officially ditched the SDK branding when we moved to my organization.

For the global object sparkle exports. So maybe "Sparkle" is better?

> By SparkleSDK, what do you mean exactly? We officially ditched the SDK branding when we moved to my organization. For the global object sparkle exports. So maybe "Sparkle" is better?

PPPDUD commented

2026-04-28 14:42:38 -05:00

(Migrated from github.com)

No! The fork will have its own Sparkle, that it has a script tag a- like now, but it must have code to call main on it.

So the fork can activate Sparkle later on instead of starting it up at once?

Yes, and it also lets you pass an object as a parameter into main, letting you do things like

crackle.main({
preloadedAddons: [
// ...
]
})

That's actually a pretty good idea! @e016 Do you think that you could implement this?

> > > No! The fork will have its own Sparkle, that it has a script tag a- like now, but it must have code to call main on it. > > > > > > So the fork can activate Sparkle later on instead of starting it up at once? > > Yes, and it also lets you pass an object as a parameter into main, letting you do things like > > > __crackle__.main({ > > preloadedAddons: [ > > // ... > > ] > > }) That's actually a pretty good idea! @e016 Do you think that you could implement this?

PPPDUD commented

2026-04-28 14:43:11 -05:00

(Migrated from github.com)

By SparkleSDK, what do you mean exactly? We officially ditched the SDK branding when we moved to my organization.

For the global object sparkle exports. So maybe "Sparkle" is better?

I would call that window.__sparkle__. It's not a pretty name, but it's rather unambiguous.

> > By SparkleSDK, what do you mean exactly? We officially ditched the SDK branding when we moved to my organization. > > For the global object sparkle exports. So maybe "Sparkle" is better? I would call that `window.__sparkle__`. It's not a pretty name, but it's rather unambiguous.

codingisfun2831t commented

2026-04-28 14:43:23 -05:00

(Migrated from github.com)

Maybe also just a Sparkle class you create and call main, kind of like Snap!'s IDE_Morph?

PPPDUD commented

2026-04-28 14:44:37 -05:00

(Migrated from github.com)

Maybe also just a Sparkle class you create and call main, kind of like Snap!'s IDE_Morph?

Actually, that would be even better!

> Maybe also just a Sparkle class you create and call main, kind of like Snap!'s IDE_Morph? Actually, that would be even better!

codingisfun2831t commented

2026-04-28 14:44:37 -05:00

(Migrated from github.com)

That's actually a pretty good idea! @e016 Do you think that you could implement this?

I would, that's why I suggested the idea :~)

> That's actually a pretty good idea! [@e016](https://github.com/e016) Do you think that you could implement this? I would, that's why I suggested the idea :~)

PPPDUD commented

2026-04-28 14:45:14 -05:00

(Migrated from github.com)

That's actually a pretty good idea! @e016 Do you think that you could implement this?

I would, that's why I suggested the idea :~)

Oh! Awesome! I assumed that you might not have been ready to develop it yet, because that's how I am with my ideas for Sparkle.

> > That's actually a pretty good idea! [@e016](https://github.com/e016) Do you think that you could implement this? > > I would, that's why I suggested the idea :~) Oh! Awesome! I assumed that you might not have been ready to develop it yet, because that's how I am with my ideas for Sparkle.

codingisfun2831t commented

2026-04-28 14:45:24 -05:00

(Migrated from github.com)

Actually, that would be even better!

Okay! Because like it would separate concerns from one another. There's no global functiona, just Sparkle functiona that like the mod manager morph gets

> Actually, that would be even better! Okay! Because like it would separate concerns from one another. There's no global functiona, just Sparkle functiona that like the mod manager morph gets

codingisfun2831t commented

2026-04-28 14:45:48 -05:00

(Migrated from github.com)

(the moprhs would have the Sparkle class passed in to the constructor)

e016 commented

2026-04-28 14:46:06 -05:00

(Migrated from github.com)

Alright! Would __crackle__ be renamed into __sparkle__, or would the two be different?

Alright! Would `__crackle__` be renamed into `__sparkle__`, or would the two be different?

codingisfun2831t commented

2026-04-28 14:47:04 -05:00

(Migrated from github.com)

Well, it would be replaced by Sparkle. The Sparkle class is just that, you then create it in another script.

e016 commented

2026-04-28 14:48:01 -05:00

(Migrated from github.com)

Well, it would be replaced by Sparkle. The Sparkle class is just that, you then create it in another script.

Oh, ok. Could it work like this?

window.__sparkle__ = new Sparkle({ parameters: [ /* ... */ ] });

> Well, it would be replaced by Sparkle. The Sparkle class is just that, you then create it in another script. Oh, ok. Could it work like this? ```js window.__sparkle__ = new Sparkle({ parameters: [ /* ... */ ] }); ```

PPPDUD commented

2026-04-28 14:48:22 -05:00

(Migrated from github.com)

Alright! Would __crackle__ be renamed into __sparkle__, or would the two be different?

I propose renaming it to Sparkle.__crackle__, where Sparkle is a Sparkle object. I think that we should still keep both, because having the name Crackle in the source code reminds us of how far we've gotten.

> Alright! Would `__crackle__` be renamed into `__sparkle__`, or would the two be different? I propose renaming it to `Sparkle.__crackle__`, where `Sparkle` is a Sparkle object. I think that we should still keep both, because having the name Crackle in the source code reminds us of how far we've gotten.

PPPDUD commented

2026-04-28 14:48:56 -05:00

(Migrated from github.com)

Well, it would be replaced by Sparkle. The Sparkle class is just that, you then create it in another script.

Oh, ok. Could it work like this?

window.sparkle = new Sparkle({ parameters: [ /* ... */ ] });

That looks good to me.

> > Well, it would be replaced by Sparkle. The Sparkle class is just that, you then create it in another script. > > Oh, ok. Could it work like this? > > window.__sparkle__ = new Sparkle({ parameters: [ /* ... */ ] }); That looks good to me.

codingisfun2831t commented

2026-04-28 14:49:58 -05:00

(Migrated from github.com)

Ill implement it on another branch!

🎉 2

e016 commented

2026-04-28 14:53:12 -05:00

(Migrated from github.com)

Alright! Would __crackle__ be renamed into __sparkle__, or would the two be different?

I propose renaming it to Sparkle.__crackle__, where Sparkle is a Sparkle object. I think that we should still keep both, because having the name Crackle in the source code reminds us of how far we've gotten.

Yeah, although I feel like that could be confusing for some devs.

> > Alright! Would `__crackle__` be renamed into `__sparkle__`, or would the two be different? > > I propose renaming it to `Sparkle.__crackle__`, where `Sparkle` is a Sparkle object. I think that we should still keep both, because having the name Crackle in the source code reminds us of how far we've gotten. Yeah, although I feel like that could be confusing for some devs.

codingisfun2831t commented

2026-04-28 14:58:19 -05:00

(Migrated from github.com)

Shouldn't it be just a global "Sparkle" or "sparkle"? We can just put a comment below Sparkle "orginally Crackle" or some easter egg in it.

Shouldn't it be just a global "Sparkle" or "__sparkle__"? We can just put a comment below Sparkle "orginally Crackle" or some easter egg in it.

PPPDUD commented

2026-04-28 15:00:49 -05:00

(Migrated from github.com)

Shouldn't it be just a global "Sparkle" or "sparkle"? We can just put a comment below Sparkle "orginally Crackle" or some easter egg in it.

If window.__crackle__ becomes sparkle, then where will we store the fork-facing APIs for Sparkle? The point of window.__crackle__ is storing internal states that shouldn't be modified by other code (hence the underscores).

> Shouldn't it be just a global "Sparkle" or "**sparkle**"? We can just put a comment below Sparkle "orginally Crackle" or some easter egg in it. If `window.__crackle__` becomes `sparkle`, then where will we store the fork-facing APIs for Sparkle? The point of `window.__crackle__` is storing internal states that shouldn't be modified by other code (hence the underscores).

codingisfun2831t commented

2026-04-28 15:34:29 -05:00

(Migrated from github.com)

If window.__crackle__ becomes sparkle, then where will we store the fork-facing APIs for Sparkle? The point of window.__crackle__ is storing internal states that shouldn't be modified by other code (hence the underscores).

Well, forks will just create the Sparkle class. And yesh, they can modify that stuff, but does that really matter?

> If `window.__crackle__` becomes `sparkle`, then where will we store the fork-facing APIs for Sparkle? The point of `window.__crackle__` is storing internal states that shouldn't be modified by other code (hence the underscores). Well, forks will just create the Sparkle class. And yesh, they can modify that stuff, but does that really matter?

PPPDUD commented

2026-04-28 15:36:43 -05:00

(Migrated from github.com)

If window.__crackle__ becomes sparkle, then where will we store the fork-facing APIs for Sparkle? The point of window.__crackle__ is storing internal states that shouldn't be modified by other code (hence the underscores).

Well, forks will just create the Sparkle class. And yesh, they can modify that stuff, but does that really matter?

Yes. It's quite possible that a fork's developer(s) might get the idea of messing with the internal state of Sparkle, under the mistaken assumption that this is supported behavior.

> > If `window.__crackle__` becomes `sparkle`, then where will we store the fork-facing APIs for Sparkle? The point of `window.__crackle__` is storing internal states that shouldn't be modified by other code (hence the underscores). > > Well, forks will just create the Sparkle class. And yesh, they can modify that stuff, but does that really matter? Yes. It's quite possible that a fork's developer(s) might get the idea of messing with the internal state of Sparkle, under the mistaken assumption that this is supported behavior.

codingisfun2831t commented

2026-04-28 15:37:40 -05:00

(Migrated from github.com)

Well, then we can document it. Or we could use # fields

PPPDUD commented

2026-04-28 15:38:28 -05:00

(Migrated from github.com)

Well, then we can document it. Or we could use # fields

What are # fields?

> Well, then we can document it. Or we could use # fields What are # fields?

codingisfun2831t commented

2026-04-28 15:39:05 -05:00

(Migrated from github.com)

PPPDUD commented

2026-04-28 15:42:26 -05:00

(Migrated from github.com)

Wouldn't those prevent forks from reading these attributes though? Using # fields would also break Jameson's Sparkle library.

> <img alt="Image" width="775" height="585" src="https://private-user-images.githubusercontent.com/124097137/585065092-44d4d064-6940-4c02-8bd7-768af3f8db70.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Nzc0MDkwODEsIm5iZiI6MTc3NzQwODc4MSwicGF0aCI6Ii8xMjQwOTcxMzcvNTg1MDY1MDkyLTQ0ZDRkMDY0LTY5NDAtNGMwMi04YmQ3LTc2OGFmM2Y4ZGI3MC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDI4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyOFQyMDM5NDFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1kZTE3YTNhZGMzNjBhNWU1MmYyMjE4ZGJmYjY4NDFjNjE5Yjc1N2IyMTBlZWE2YWI1MjQ3NTRmZDMxY2JmZjg0JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.vAIdJOMJ9miBdxN_JVsNd1MjoztzlbWu0PBsbKj9cxo"> Wouldn't those prevent forks from reading these attributes though? Using # fields would also break Jameson's Sparkle library.

codingisfun2831t commented

2026-04-28 15:45:50 -05:00

(Migrated from github.com)

Wouldn't those prevent forks from reading these attributes though? Using # fields would also break Jameson's Sparkle library.

True.. What do you propose?

> Wouldn't those prevent forks from reading these attributes though? Using # fields would also break Jameson's Sparkle library. True.. What do you propose?

PPPDUD commented

2026-04-28 15:46:10 -05:00

(Migrated from github.com)

Wouldn't those prevent forks from reading these attributes though? Using # fields would also break Jameson's Sparkle library.

True.. What do you propose?

Sparkle.__crackle__.

> > Wouldn't those prevent forks from reading these attributes though? Using # fields would also break Jameson's Sparkle library. > > True.. What do you propose? `Sparkle.__crackle__`.

Rows
Columns

Preloaded addons #23

API layout

UI/UX aspects