Options api

e016 commented

2026-04-14 11:52:58 -05:00

(Migrated from github.com)

Implements the Options API, as in issue #3. It doesn't work properly in Split! Dark mode yet, though.

<img width="429" height="258" alt="image" src="https://github.com/user-attachments/assets/056882e0-000b-4927-9c79-c24de5202560" /> Implements the Options API, as in issue #3. It doesn't work properly in Split! Dark mode yet, though.

🎉 1

e016 commented

2026-04-17 11:56:54 -05:00

(Migrated from github.com)

I have finished adding dropdowns and arrays:

Anything else, or any bugs?

I have finished adding dropdowns and arrays: <img width="431" height="375" alt="image" src="https://github.com/user-attachments/assets/74e47b43-d036-482d-b78a-7e1b9200d344" /> Anything else, or any bugs?

PPPDUD commented

2026-04-17 14:48:24 -05:00

(Migrated from github.com)

Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in main? Is there any reason for this discrepancy?

Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in `main`? Is there any reason for this discrepancy?

e016 commented

2026-04-17 14:49:49 -05:00

(Migrated from github.com)

Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in main? Is there any reason for this discrepancy?

That's @codingisfun2831t's fault, he made the Snaps and (I think...) the menu options. I think we could put everything in the returned class now.

> Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in `main`? Is there any reason for this discrepancy? That's @codingisfun2831t's fault, he made the Snaps and (I think...) the menu options. I think we could put everything in the returned class now.

PPPDUD commented

2026-04-17 14:50:56 -05:00

(Migrated from github.com)

Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in main? Is there any reason for this discrepancy?

That's @codingisfun2831t's fault, he made the Snaps and (I think...) the menu options. I think we could put everything in the returned class now.

I would actually push for the opposite path: everything that's not metadata goes in a function, that way addons can dynamically change UI elements as they go and do other fun stuff. Also, can we make it to where addons have to specifically trigger the options menu and can add menu items for this?

> > Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in `main`? Is there any reason for this discrepancy? > > That's @codingisfun2831t's fault, he made the Snaps and (I think...) the menu options. I think we could put everything in the returned class now. I would actually push for the opposite path: everything that's not metadata goes in a function, that way addons can dynamically change UI elements as they go and do other fun stuff. Also, can we make it to where addons have to specifically trigger the options menu and can add menu items for this?

e016 commented

2026-04-17 14:53:21 -05:00

(Migrated from github.com)

Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in main? Is there any reason for this discrepancy?

That's @codingisfun2831t's fault, he made the Snaps and (I think...) the menu options. I think we could put everything in the returned class now.

I would actually push for the opposite path: everything that's not metadata goes in a function.

I get why but... shouldn't at least Snap compatability be metadata? It's not like you're going to change the compatibilitiness of your addon on the fly.

I think separating the menu into its own function would be a good idea.

> > > Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in `main`? Is there any reason for this discrepancy? > > > > > > That's @codingisfun2831t's fault, he made the Snaps and (I think...) the menu options. I think we could put everything in the returned class now. > > I would actually push for the opposite path: everything that's not metadata goes in a function. I get why but... shouldn't _at least_ Snap compatability be metadata? It's not like you're going to change the compatibilitiness of your addon on the fly. I think separating the menu into its own function would be a good idea.

PPPDUD commented

2026-04-17 14:56:03 -05:00

(Migrated from github.com)

Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in main? Is there any reason for this discrepancy?

That's @codingisfun2831t's fault, he made the Snaps and (I think...) the menu options. I think we could put everything in the returned class now.

I would actually push for the opposite path: everything that's not metadata goes in a function.

I get why but... shouldn't at least Snap compatability be metadata? It's not like you're going to change the compatibilitiness of your addon on the fly.

Well, I don't see any convincing reason to intentionally prevent that.

I think separating the menu into its own function would be a good idea.

Why would that be a good idea?

> > > > Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in `main`? Is there any reason for this discrepancy? > > > > > > > > > That's @codingisfun2831t's fault, he made the Snaps and (I think...) the menu options. I think we could put everything in the returned class now. > > > > > > I would actually push for the opposite path: everything that's not metadata goes in a function. > > I get why but... shouldn't _at least_ Snap compatability be metadata? It's not like you're going to change the compatibilitiness of your addon on the fly. > Well, I don't see any convincing reason to intentionally _prevent_ that. > I think separating the menu into its own function would be a good idea. Why would that be a good idea?

e016 commented

2026-04-17 14:59:35 -05:00

(Migrated from github.com)

I think separating the menu into its own function would be a good idea.

Why would that be a good idea?

To keep things organised:

// ...

menu: function () {
    return new MenuMorph()
},
main() {
   // ...
}

// ...

> > I think separating the menu into its own function would be a good idea. > > Why would that be a good idea? To keep things organised: ``` // ... menu: function () { return new MenuMorph() }, main() { // ... } // ... ```

e016 commented

2026-04-17 15:05:02 -05:00

(Migrated from github.com)

dynamically change UI elements as they go and do other fun stuff

What UI elements? You can already add hooks and apply warpFunction to stuff.
This doesn't have anything to do with dissalowing snap mods on the fly and changing options whenever you want to with code.

I think an event for when the options have been changed is a good idea, though.

> dynamically change UI elements as they go and do other fun stuff What UI elements? You can already add hooks and apply `warpFunction` to stuff. This doesn't have anything to do with dissalowing snap mods on the fly and changing options whenever you want to with code. I think an event for when the options have been changed is a good idea, though.

PPPDUD commented

2026-04-17 15:15:46 -05:00

(Migrated from github.com)

I think separating the menu into its own function would be a good idea.

Why would that be a good idea?

To keep things organised:
// ...

menu: function () {
    return new MenuMorph()
},
main() {
   // ...
}

// ...

Wouldn't that unnecessarily break backwards compatibility in newer addons?

> > > I think separating the menu into its own function would be a good idea. > > > > > > Why would that be a good idea? > > To keep things organised: > > ``` > // ... > > menu: function () { > return new MenuMorph() > }, > main() { > // ... > } > > // ... > ``` Wouldn't that unnecessarily break backwards compatibility in newer addons?

PPPDUD commented

2026-04-17 15:16:04 -05:00

(Migrated from github.com)

Whoops didn't mean to close, sorry!

codingisfun2831t commented

2026-04-17 15:18:01 -05:00

(Migrated from github.com)

LGTM

Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in main? Is there any reason for this discrepancy?

That's what did, originally. However, I think its definitely better as a function. So, any person who e.g. makes a clipboard addon, can provide a export feature if and ONLY if there's data there. This is how the morphic right-click menu feature works, you provide a "userMenu" function that returns a menu.

For that disallowed snaps, I did that so, in theory, you could check for a version or such and popup something. However it might be better to make all of that a string list, kinda like Python requirements.txt.

And justa little note, sorry for being mean and all about management. I like what you all are doing for the code itself, but of course I don't really agree with the addons replace forks. However, I am actually starting to change my mind.. it's just that, for forks they change a lot of stuff about Snap! Itself, that's going to be hard for addons. If we can get any system to work better with that and improve the whole system, I can get behind that.

LGTM > Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in `main`? Is there any reason for this discrepancy? That's what did, originally. However, I think its definitely better as a function. So, any person who e.g. makes a clipboard addon, can provide a export feature if and ONLY if there's data there. This is how the morphic right-click menu feature works, you provide a "userMenu" function that returns a menu. For that disallowed snaps, I did that so, in theory, you could check for a version or such and popup something. However it might be better to make all of that a string list, kinda like Python requirements.txt. And justa little note, sorry for being mean and all about management. I like what you all are doing for the code itself, but of course I don't really agree with the addons replace forks. However, I am actually starting to change my mind.. it's just that, for forks they change a lot of stuff about Snap! Itself, that's going to be hard for addons. If we can get any system to work better with that and improve the whole system, I can get behind that.

PPPDUD commented

2026-04-17 15:18:47 -05:00

(Migrated from github.com)

dynamically change UI elements as they go and do other fun stuff

What UI elements? You can already add hooks and apply warpFunction to stuff. This doesn't have anything to do with dissalowing snap mods on the fly and changing options whenever you want to with code.

Options in the Sparkle menu and stuff like that. While I don't think that there's any good reason to be doing tomfoolery like what you described, it's best to keep support for edge cases like that because it wouldn't cause any harm.

I think an event for when the options have been changed is a good idea, though.

Agreed.

> > dynamically change UI elements as they go and do other fun stuff > > What UI elements? You can already add hooks and apply `warpFunction` to stuff. This doesn't have anything to do with dissalowing snap mods on the fly and changing options whenever you want to with code. > Options in the Sparkle menu and stuff like that. While I don't think that there's any good reason to be doing tomfoolery like what you described, it's best to keep support for edge cases like that because it wouldn't cause any harm. > I think an event for when the options have been changed is a good idea, though. Agreed.

PPPDUD commented

2026-04-17 15:25:06 -05:00

(Migrated from github.com)

LGTM

Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in main? Is there any reason for this discrepancy?

That's what did, originally. However, I think its definitely better as a function. So, any person who e.g. makes a clipboard addon, can provide a export feature if and ONLY if there's data there. This is how the morphic right-click menu feature works, you provide a "userMenu" function that returns a menu.

Agreed.

For that disallowed snaps, I did that so, in theory, you could check for a version or such and popup something. However it might be better to make all of that a string list, kinda like Python requirements.txt.

Perhaps, but I think that the API's fine as it is personally.

And justa little note, sorry for being mean and all about management.

Don't worry! People are routinely much harder on me than you have ever been, and I think that it's important to have someone like you to keep us from shooting for the moon and having the bullets land squarely in our feet.

I like what you all are doing for the code itself, but of course I don't really agree with the addons replace forks. However, I am actually starting to change my mind.. it's just that, for forks they change a lot of stuff about Snap! Itself, that's going to be hard for addons. If we can get any system to work better with that and improve the whole system, I can get behind that.

We'll get it done, piece by piece. The first step is integrating Sparkle into Jameson, which is planned for sometime this Sunday. Next up, we'll start gathering up features from forks and create a centralized repository of libraries. I'm not sure what the final step is yet, but I'm sure it's great.

> LGTM > > > Partially unrelated, but why is it that the options configs are defined in the returned class, but stuff like Sparkle menu options and disallowed Snaps are handled in `main`? Is there any reason for this discrepancy? > > That's what did, originally. However, I think its definitely better as a function. So, any person who e.g. makes a clipboard addon, can provide a export feature if and ONLY if there's data there. This is how the morphic right-click menu feature works, you provide a "userMenu" function that returns a menu. > Agreed. > For that disallowed snaps, I did that so, in theory, you could check for a version or such and popup something. However it might be better to make all of that a string list, kinda like Python requirements.txt. > Perhaps, but I think that the API's fine as it is personally. > And justa little note, sorry for being mean and all about management. Don't worry! People are routinely much harder on me than you have ever been, and I think that it's important to have someone like you to keep us from shooting for the moon and having the bullets land squarely in our feet. > I like what you all are doing for the code itself, but of course I don't really agree with the addons replace forks. However, I am actually starting to change my mind.. it's just that, for forks they change a lot of stuff about Snap! Itself, that's going to be hard for addons. If we can get any system to work better with that and improve the whole system, I can get behind that. We'll get it done, piece by piece. The first step is integrating Sparkle into Jameson, which is planned for sometime this Sunday. Next up, we'll start gathering up features from forks and create a centralized repository of libraries. I'm not sure what the final step is yet, but I'm sure it's great.

codingisfun2831t commented

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

(Migrated from github.com)

Yeah to be completey honest I've grown to like the idea. We can have stuff that will allow projects to check about stuff, of course, and it should be good!

👍 1

codingisfun2831t commented

2026-04-17 17:23:40 -05:00

(Migrated from github.com)

Actually I do have a worry. DO NOT MAKE THE EXTENSION CEASE TO EXIST! No one wants to be forced to use Jameson for Sparkle! For example, lets take Scratch Addons. Its a extension if you use Scratch, but Turbowarp intergrates it. And that's fine! But Sparkle should still be a seperate extension, and follow off that whole thing.

PPPDUD commented

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

(Migrated from github.com)

Actually I do have a worry. DO NOT MAKE THE EXTENSION CEASE TO EXIST! No one wants to be forced to use Jameson for Sparkle! For example, lets take Scratch Addons. Its a extension if you use Scratch, but Turbowarp intergrates it. And that's fine! But Sparkle should still be a seperate extension, and follow off that whole thing.

Woah man! Calm down! I'm not trying to nix the extension anytime soon. It's still useful for Snap!, and unless they do something to mess up compatibility with Sparkle, I don't plan on stopping releases of the extension.

> Actually I do have a worry. DO NOT MAKE THE EXTENSION CEASE TO EXIST! No one wants to be forced to use Jameson for Sparkle! For example, lets take Scratch Addons. Its a extension if you use Scratch, but Turbowarp intergrates it. And that's fine! But Sparkle should still be a seperate extension, and follow off that whole thing. Woah man! Calm down! I'm not trying to nix the extension anytime soon. It's still useful for Snap!, and unless they do something to mess up compatibility with Sparkle, I don't plan on stopping releases of the extension.

🎉 1

codingisfun2831t commented

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

(Migrated from github.com)

Woah man! Calm down! I'm not trying to nix the extension anytime soon. It's still useful for Snap!, and unless they do something to mess up compatibility with Sparkle, I don't plan on stopping releases of the extension.

Good! I did overreact. Just make Jameson be updated every main release for Sparkle with the new extension. The end goal, perhaps, is to get the Snap! Team to integrate sparkle? But that probably won't happen. :~)

> Woah man! Calm down! I'm not trying to nix the extension anytime soon. It's still useful for Snap!, and unless they do something to mess up compatibility with Sparkle, I don't plan on stopping releases of the extension. Good! I did overreact. Just make Jameson be updated every main release for Sparkle with the new extension. The end goal, perhaps, is to get the Snap! Team to integrate sparkle? But that probably won't happen. :~)

PPPDUD commented

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

(Migrated from github.com)

Woah man! Calm down! I'm not trying to nix the extension anytime soon. It's still useful for Snap!, and unless they do something to mess up compatibility with Sparkle, I don't plan on stopping releases of the extension.

Good! I did overreact. Just make Jameson be updated every main release for Sparkle with the new extension. The end goal, perhaps, is to get the Snap! Team to integrate sparkle? But that probably won't happen. :~)

I suppose that trying to get the Snap! Team to integrate our codebase would be one path, but they don't seem to be very receptive to PRs. I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether.

> > Woah man! Calm down! I'm not trying to nix the extension anytime soon. It's still useful for Snap!, and unless they do something to mess up compatibility with Sparkle, I don't plan on stopping releases of the extension. > > Good! I did overreact. Just make Jameson be updated every main release for Sparkle with the new extension. The end goal, perhaps, is to get the Snap! Team to integrate sparkle? But that probably won't happen. :~) I suppose that trying to get the Snap! Team to integrate our codebase would be one path, but they don't seem to be very receptive to PRs. I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether.

codingisfun2831t commented

2026-04-17 17:48:57 -05:00

(Migrated from github.com)

I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether.

Woah! That's a bit much!

> I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether. Woah! That's a bit much!

PPPDUD commented

2026-04-17 17:50:12 -05:00

(Migrated from github.com)

I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether.

Woah! That's a bit much!

True. I wouldn't mind if that didn't happen either.

> > I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether. > > Woah! That's a bit much! True. I wouldn't mind if that didn't happen either.

e016 commented

2026-04-17 17:50:43 -05:00

(Migrated from github.com)

I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether.

Woah! That's a bit much!

Yeah, some of @PPPDUD's other messages seem to imply that you should "use Jameson" and only keep the extension for when you need regular stock Snap.

_(ninja'd)

> > I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether. > > Woah! That's a bit much! Yeah, some of @PPPDUD's other messages seem to imply that you should "use Jameson" and only keep the extension for when you need regular stock Snap. <sub>(ninja'd)</sub>

PPPDUD commented

2026-04-17 17:53:52 -05:00

(Migrated from github.com)

I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether.

Woah! That's a bit much!

Yeah, some of @PPPDUD's other messages seem to imply that you should "use Jameson" and only keep the extension for when you need regular stock Snap.

(ninja'd)

Exactly. The goal of the extension is to make life easier for the people who need Snap! in particular for some reason.

> > > I would prefer a solution where we create our own repository of projects (and potentially a forum site), so as to replace Snap! altogether. > > > > > > Woah! That's a bit much! > > Yeah, some of @PPPDUD's other messages seem to imply that you should "use Jameson" and only keep the extension for when you need regular stock Snap. > > (ninja'd) Exactly. The goal of the extension is to make life easier for the people who need Snap! in particular for some reason.

codingisfun2831t commented

2026-04-17 18:01:30 -05:00

(Migrated from github.com)

Snap! in particular for some reason.

...Because its Snap!.

> Snap! in particular for some reason. ...Because its Snap!.

codingisfun2831t commented

2026-04-17 18:01:59 -05:00

(Migrated from github.com)

But seriously you should'nt make the main way to use jameson

PPPDUD commented

2026-04-17 18:04:51 -05:00

(Migrated from github.com)

Snap! in particular for some reason.

...Because its Snap!.

What specific quality of Snap! makes it better than Jameson in your eyes?

But seriously you should'nt make the main way to use jameson

Just because the "main" way will be Jameson doesn't mean that I'm deprioritizing support for Snap!; they're still an important market!

> > Snap! in particular for some reason. > > ...Because its Snap!. What specific quality of Snap! makes it better than Jameson in your eyes? > But seriously you should'nt make the main way to use jameson Just because the "main" way will be Jameson doesn't mean that I'm deprioritizing support for Snap!; they're still an important market!

codingisfun2831t commented

2026-04-17 18:06:32 -05:00

(Migrated from github.com)

What specific quality of Snap! makes it better than Jameson in your eyes?

That's its the original?? Most people will trust Snap! instead of some random fork of it, that may or may not be stable/bug free.

> What specific quality of Snap! makes it better than Jameson in your eyes? That's its the original?? Most people will trust Snap! instead of some random fork of it, that may or may not be stable/bug free.

PPPDUD commented

2026-04-17 18:07:59 -05:00

(Migrated from github.com)

What specific quality of Snap! makes it better than Jameson in your eyes?

That's its the original?? Most people will trust Snap! instead of some random fork of it, that may or may not be stable/bug free.

While I understand that Snap! has better word-of-mouth and trust among the community, I beg you to judge this book by the preface and not just the cover.

> > What specific quality of Snap! makes it better than Jameson in your eyes? > > That's its the original?? Most people will trust Snap! instead of some random fork of it, that may or may not be stable/bug free. While I understand that Snap! has better word-of-mouth and trust among the community, I beg you to judge this book by the preface and not just the cover.

codingisfun2831t commented

2026-04-17 18:10:14 -05:00

(Migrated from github.com)

While I understand that Snap! has better word-of-mouth and trust among the community, I beg you to judge this book by the preface and not just the cover.

Simple reason: older version

> While I understand that Snap! has better word-of-mouth and trust among the community, I beg you to judge this book by the preface and not just the cover. Simple reason: older version

e016 commented

2026-04-17 18:53:56 -05:00

(Migrated from github.com)

By the way, can we move the modding discussion in a new issue? Thanks.

I've added a new "optionsChanged" event for Mod classes:

By the way, can we move the modding discussion in a new issue? Thanks. I've added a new "optionsChanged" event for `Mod` classes: <img width="449" height="94" alt="image" src="https://github.com/user-attachments/assets/6839d4a1-b698-412d-a28a-d7e51dd1f0c1" />

🎉 1

e016 commented

2026-04-19 14:42:35 -05:00

(Migrated from github.com)

I'll pull this now, to have the options ready for v0.4!!!

🎉 1

Rows
Columns

Options api #20