Some things to work on before the first stable release #3
Labels
No labels
bug
discussion
documentation
duplicate
enhancement
good first issue
help wanted
invalid
Jameson
joke
options window
question
Split!
wontfix
No milestone
No project
No assignees
1 participant
No due date set.
Dependencies
No dependencies set
Reference
sparkle-devs/sparkle-old-migration#3
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Addon installation and management
mods.jsonautomatically upon every commitOptions API
Branding
If any of you all know how to implement these, please open a PR!
@Mojavesoft-Group/sparkle-team I've written a GitHub actions bot on the mods repo that automatically regenerates
mods.jsonas needed. What do you all think?Cool! This will be useful!!!
Agreed! I wrote it because I was irked by the idea of having to use Node.js, one of my least-favorite programming languages, on my own machine just to submit an extension.
@Mojavesoft-Group/sparkle-team I made the first release of Sparkle; would you all please test it out for me when you have some time?
One request: can the logo be improved? First, it has a white background, and second; I think a "Sparkle!" text next to it would make it better. I do like the style of it, just a transparent background and that text would help. And sure, I'll test it out!
And also, can the commits PLEASE be convetional commits from now on? I keep seeing random "Update index.js" without any other info...
And also (again..) can we please switch to a seperate organization? It feels right "SparkleSDK" for the name or such, and with it we could also provide a profile picture for the project.
And (again) why is there a build.sh? I get it, its for packaging, but then shouldnt it be named "package.sh"? Im going to rename it and also make it package Firefox extensions.
And actually nevermind that, shouldn't we just use a packager like web-ext? Even without TypeScript it'll still allow for a better development workflow. (we could seperate the code into multiple files!)
Holy guacamole @codingisfun2831t! That's a lot of requests!
I'll see what I can do.
If we try to organize ourselves much more, I fear that we'll fail under the pressure of bureaucracy. In my opinion, even setting out a basic roadmap and opening PRs was too much.
Go ahead, but if something breaks but only on Firefox, I will not be the one fixing it.
We have like five users, most of whom are contributors and don't actually use Sparkle. Let's wait until we have a more substantial userbase before doing anything too wild with organizations.
I don't think that it's wise to make Node.js a dependency for packaging.
In general, I appreciate your feedback, but I think that we're trying to move in very different directions over all, and in doing so we are stepping over each other constantly.
I propose that we have two projects. Sparkle shall be a Chromium extension owned and operated by me and @e016, and you can start a fork (with its own org!) named Crackle that's built specifically for Firefox users.
If you go through with this, I will expect that all major changes in Crackle be proposed in a PR to Sparkle.
What? I've never used firefox but surley
isn't too far of a stretch to apply to Sparkle! Maybe a branch on the repo could be used for adding firefox support?
We only have three developers, and two of them are constantly in disagreement, so I don't think that it's wise to try and support both Chromium and Firefox in one project.
See #10.
@codingisfun2831t I've improved the logo for the README; it's not transparent, but it has some nice text and it looks much nicer in my opinion.
WHY are you so afraid of Firefox?? Did the fox jump out at you in a nightmare or something?? Its not like Chrome is the best either! Seriously, get ahold of yourself. Its not THAT MUCH of an ask to have two platforms...
I don't like either, but every time I open Firefox, I am bombarded with news stories about Trudeau and Katy Perry falling in love while it takes 30 seconds to load everything. Before that, I developed a competing product (WorldExplorer), which they sent crashing and burning without even knowing that it existed.
Firefox is more importantly a pain to develop for, because they insist that you publish extensions through their official means rather than sideloading.
There's a little edit icon to disable the news...
I didn't realize that, thanks for sharing!
Let's move discussion of branding and Firefox to #10 for now, shall we?
Oh yeah, totally, your one person team made a big browser, which is most probably just a fork.
You can easily just disable both of that.. Put a bit more effort and boom the browser works well!
Crackle/Sparkle isn't that big at the moment, and eventually it will be published on there and Chrome. I get it, that is bad, but you can just disable the whole signing thing or such. So its simple, just temporary load the extension for testing or do that for permanent-ish sideloading. And besides, someone else (like me, who uses Firefox all the time!) can develop for it.
In retrospect, WorldExplorer was one of my worst projects that I actually marketed to people. I make no claim that was ever good.
Also, Firefox doesn't support most of the cool JavaScript APIs that Chromium does, but I think that discussing the merits of Firefox as an end-user product are beyond the scope of this discussion. Our opinions in that area have little bearing on Crackle/Sparkle development.
I would be fine with letting you develop for Firefox, but I really, really don't want to have to touch it with a 10-foot stick if I can avoid it.
Again, repo branches will help us...
What JS APIs? If so, I'm sure it probably wont hinder us, as the thousands of Firefox extension developers behind us.
Okay, then its fine!
It would be really unruly if we had two seperate branches with the exact same branding and a shared Releases tab, but they're built by different people for different platforms. Perhaps we could hack together something with GitHub Actions that builds for both targets from our current codebase without adding any special project files or anything?
OR we could just have firefox support IN THE MAIN BRANCH and let me handle it! Groundbreaking, you know?
I might be fine with that, but only if I don't need to install some random npm package to make it work.
Really? I get how bureaucracy can slow us down, but using conventional commits that much organised for "organizing ourselves much more."
Also, it helps if half of the commits don't have the exact same name. Even in my repos which don't follow any sort of guidelines, I still try to say what's going on:
I like the idea of the logo, although I do wish that the letters were all the same size... the text looks like it's fading out.
I really don't like the hard drawn text.. and for the transparency just put it in a online tool!
The editor that I use (Piskel) does not support filling with transparency, which makes transparent logos a pain (also getting a good contrast with the GitHub UI on both light and dark mode is a challenge). My editor also doesn't support text, but I think that my somewhat-mediocre handwriting gives the right message overall: made by imperfect humans, for imperfect humans.
Yeah; there's nothing wrong with hand-drawn text; I want the imperfect letters! I just wish the letters were roughly the same size:
I think I'll try make a transparent version for the "About Sparkle" popup
Also, can the wand be a bit thicker? It's hard to see in the small extension icon:
Will see what I can do.
@e016 What do you think about these images I drew up?
Here's how the new logo looks in Chromium:
@e016 @codingisfun2831t Any opinions on the new logo design?
It's great, but there's a dent on the staff!
That's a good point, will fix soon; thanks!
No problem! In the mean time, I'll try adding a search bar to the addon download portal!
Awesome!
@e016 I've done a bit more work on the logo; what do you think?
I like the wand now!
Also, why does the text curve now?
I'm not very good at writing with a mouse, so stuff like that comes up pretty frequently.
Here's a version with less obvious curvature in the text:
Thanks! Just move the text just slightly higher, as the last few letters are almost touching the floor.
Other than that, it's perfect!
@e016 What about this version?
Great!
I've updated the logos accordingly.
@codingisfun2831t @e016 What do you think about another release today?
@Mojavesoft-Group/jameson-team Released v0.2 today; what do you all think?
@e016 @codingisfun2831t I have recently become aware of #15 and #14, where GitHub did not alert me to the creation of a new issue, preventing me from helping out.
I have instructed GitHub to watch all activity on this repo; I suggest that you all do as well.
P.S. I'm hoping to publish v0.3 before or on the 10th. @e016 @Bubgamer07 I'm still waiting on your opinions on #12; we can't go forward with relicensing until both of you consent.
By the way, don't forget to implement ego-lay-atman-bay's options API! (Issue is in the archived Crackle repo)
Will plan to do so soon, thanks.
Also, can I edit the OP to include the options API?
Yes.
@codingisfun2831t @e016 Addon development is getting backed up because the
api.storageAPI isn't available in Sparkle yet, so I would like to release v0.4 by April 19th. Please finalize all major API or documentation changes before then.To be honest it seems like youre trying to do everything too fast. You want this to be professional, sure, but is that really what this should be? This is a community project, stop being so tight about everything! I might be too laid back, but...
Back in the days when Crackle was still around, I thought that the governance was too lax. There were only two releases, at seemingly-random intervals, and users were basically expected to clone the (unstable!) master branch in order to obtain an actually-usable copy. When the exodus happened and the maintainers fled to my leadership, I decided early on that I would keep a tighter ship than you all did before.
A side effect of this is that everything follows a rigid schedule of 1 release per week, every week. I apologize for being so strict, but I feel strongly that this project will begin to fall apart if the rigidity disappears.
Edit: I realize that this comment could be construed as a criticism of Crackle's development, which you held a large part in. For the record, I have nothing against you as a person or contributor, and I think that you're an excellent developer, but I do think that it's best to leave the scheduling details to me.
Edit 2: Adding to this a bit: Back when @e016 was working on CrackleTeam/CrackleSDK#26, they added me as a "developer" in the about screen. It was at this point that I decided to be an orchestrator instead; someone who did the boring organizational work so that the actual developers could write high-quality code. That's why I let you and @e016 commit major changes without my oversight. It's because you know better than I do. My job is to add little tidbits in the code, keep the Markdown files pretty, and make sure that you all don't devolve into an anarchy.
Wouldn't "Manager" work better than "Orchestrator"?
Thanks, though. These words were quite nice!
Seriously? Crackle was, and still is, in heavy development! I wasn't expecting anyone to use it seriously, thus I didn't provide much stuff! And seriously, release every week? It's fine for like, snapshots (like how Minecraft does it), but not for releases! And it only fell apart simply because Tethrarxitet wasn't there. You definitely helped it get back up, sure, but your treating this like it's some full featured product, which it isn't! Sorry if I'm coming out mean, I don't want any fist fights over this but it's useful to get it out before continuing!
And before any of this, we didn't even really know you! Well I kind of did, mainly because... You've already asked me for my Snap!Docs thing for Jameson (or have you? Maybe this is a failed point). You seem to like invading on random Snap! related projects just to feel something. Sure, I'm not Tethrarxitet, the original developer (well, to be fair, idea maker) which then I provided my Snap!Mods base and actually brought it to life! You just randomly came along...
Technically, yes, but orchestrator sounds more poetic.
Happy to help!
The releases are snapshots, pretty much. Notice how each release follows the v0.x.x pattern? The major version 0 in semver has a special meaning: you can make major, breaking changes at any time without incrementing that number to 1.
Also, one of the main reasons (besides those already mentioned) that I'm so invested in pushing out this product is because I am going to make it the official modding system for Jameson (@e016 if you want to do this for Split! too, feel free, there's instructions in the documentation folder).
True. One of the primary goals of Jameson is to integrate all of the best ideas from the community in one place, so that you all don't need to manually import libraries and enable JS extensions just to get anything done. When I learned of Crackle, I quickly realized that if it took off, it could mean the end of Snap! modding as we knew it, effectively killing Jameson, Split!, Snavanced!, etc. I also realized that if it worked out, all of the best bits and pieces would become the domain of one fork.
The current focus of Jameson is to become that one fork. If and when Sparkle catches on, I want to invite the developers of each of the major forks to contribute their changes in modular addons, so Jameson users will receive the best of all worlds.
Not really- Sparkle's meant for adding visual/helper tools, not new blocks that would make stuff incompatible with regular snap.
It is true that everything else would be killed by Sparkle...
Well, it's only a matter of time before someone writes an addon that lets you import from a centralized repository of libraries.
Agreed.
Not at all! Crackle is meant for visual stuff, like what @e016 said:
No no! It wouldn't! Snap forks can still exist and have! Sparkle/Crackle is about again, visual tools and not blocks. Even with Split, you can add addons. Snap forks should exist.
If you're talking about something like personal libraries, of course that's fine! If you're talking about adding new extensions or such, that's not good. Eventually, if you remember correctly from the Split cloud saga where I tried to start up a Snap!Cloud server to add cloud Support to Split!, bh did talk a future where "mods could be on the Snap! Website itself and projects could link to their mod", but thats later. That might help?
Sigh.. again, trying to push that into everything! I don't really think that's the best...
Oh, that's makes sense. Just use the snapshot mark for after that.
By "everything else would be killed by Sparkle" I mean visual mod features (e.g: Snavanced flat design/themes, Split! blocks and UI, etc...)
Yeah, @PPPDUD told me to add something about this personal library library; so it's not about adding extensions with others.
While I agree that the original purpose of Crackle was skins and other visual aspects, I think that it's shortsighted to stop there. Just about every feature that makes a fork special can be implemented with Sparkle addons, given enough effort.
What do you mean by extensions? Primitives?
Well, I suppose that you're entitled to your own opinions.
Pigs will fly before we get a stable release at this rate.
True, but then you'll have tons of errors and bugs when opening your project if you don't have Sparkle.
IIRC, Scratch Addons has an (unspoken? I've seen it by a dev) rule about everything being compatible with Scratch.
Well, that's just another reason for people to use Sparkle.
Wowww.. Seriously? People should not have to use a random extension for any Snap! project. Are you out of your mind??
They won't, if my integration system works out. The future mega-fork of Snap! (hopefully Jameson!) will come with Sparkle pre-installed. Compare this to TurboWarp extensions, for example. Projects written with TurboWarp extensions cannot be uploaded to Scratch and there are few-to-no browser extensions to improve compatibility between the two. With Sparkle, projects written with nonstandard Sparkle addons will still be able to load on stock Snap!, and many if not most features will still work just fine. For the few scenarios where this would not be the case, users could use a fork that integrates Sparkle by default or install the Sparkle extension.
So you still want Snap! forks, AND an optional Sparkle addon? I thought you said that Sparkle could replace everything!
I think you also mean integrating Sparkle into your Snap Mod and have it always load an addon that makes your mod special.
Just about, yes. I want a Snap! fork with Sparkle already integrated, such that the distinguishing features of each other mod can be written as addons that the user can add or remove at will in order to create their desired development environment. In doing so, there would no longer be any need for having several separate forks, because users would be able to download all of the different gizmos in one place.
The optional browser extension would be for people who still needed to use stock Snap! for some reason.
Edit: My previous comment had some mistaken info that conflicts with the ideas presented here; I'm fixing it now.
Youre taking all of this way out of what it was supposed to be. You come in here randomly trying to take over the project, which I reluctantly agreed because I too was tired of Tethrarxixet not being online. And then now you try to push this Sparkle thing (which by the way, is a arguably worse name than Crackle, but thats just my opinion; not important) into every nook and cranny trying to make it replace every fork (which is stupid...)
And sure, I can accept having a "sparkle?" extension that projects can simply check if it exists (or another way to detect it and other mods). But that is not what it should be! New block features/other new project-related features should be in forks, and--in theory, if the Snap! team ever implements it-- a magical system to allow opening a project that requires, e.g. Snavanced!, to load into that. But that's not implemented for now (maybe after Snap! v12? I dont know, I'm not on the team of course). And I really just don't like the idea of a "Snavanced Addon". If, perchance, the Snap! team gets something sorted out and uses Sparkle, sure; thats fine. But for now I really don't like the stance you have.
TL;DR, Sparkle should be visual/helper tools, not adding new features/blocks.
I think the reason for this is for mod combos, like Split + Snavanced or Jameson + Snavanced, etc.
Well, if we aim too high, it'll be alright. I don't anticipate anybody getting harmed if this doesn't work out.
My idea is not so much a single Snavanced! addon, but a number of smaller addons for themes, blocks, icons, etc.
Precisely.
I think addons should have an
INCOMPATIBLEproperty if the Sparkle empire takes over Snap! mods; for addons that add new blocks/featuresHow would users benefit from this property? Would it show a warning or something?
Yes, it would show a warning if you're using the extension in vanilla snap
On every load or just the first time that it's added?
Just the first time, there's no need to show it all the time. It's sort of like the suggestSnaps and dissallowSnaps thing (which would be nearly obsolete with your plan)
Sounds good. I might implement it at some point.
I agree. And we should have the sparkle_ extensions, and a tutorial on how to use them (perhaps a library that allows you to, e.g. check if Sparkle exists, if a mod exists, etc?)
Jameson already has basic support for this, though it's not exhaustive:
Yeah, but that should be in a form via extensions, that then a library (from Sparkle) can detect if they exist (thus, a sparkle dectected) and get stuff like version, or dev, or mods, etc.
The primitives required for this library are supplied in the Jameson Compatibility addon, and I plan on sharing this library with other forks using the Personal Libraries addon once Mojavesoft-Group/SparkleMods#10 gets implemented.
Yeah, but its better to be in Sparkle itself (so people can detect if a user has mods a project needs!)
I don't think that we should include Snap! primitives in Sparkle. It's the job of forks to ensure that they have sufficient primitives for whatever tasks their projects might require, and if they fail at that job, their primitives should be supplemented by addons and not Sparkle.
I wouldn't be opposed to an addon that adds these primitives and nothing else though.
@Mojavesoft-Group/sparkle-team Released v0.4!!!
Great news everyone! I've added automated code formatting for the Sparkle and SparkleMods repos! That means that you all are free to use inconsistent indentation, single-line if statements, etc. and GitHub Actions will clean it up for you when you commit to main! See also #22.
@Mojavesoft-Group/sparkle-team Released v0.5!!!
@codingisfun2831t If you use an AI-enabled IDE like VSCode, please make sure to avoid using Copilot (including inline suggestions), because all code in this project must be written by humans. I'm letting you know because @e016 did this by accident and had to have their PR closed.
@Mojavesoft-Group/sparkle-team Please wrap up all development for v0.6 by May 3rd. @codingisfun2831t How's progress on your Sparkle-as-a-class system? Should we wait for it to finish or are we going to push its launch to v0.7? Either way is fine with me.
Ill probably finish it later today or tomorrow, currently I'm doing some free-time-ness :~)
Cool, me too. No rush, if you don't meet the deadline we can delay it before releasing v0.6 ;).
@Mojavesoft-Group/sparkle-team I am delaying v0.6 to May 4th for personal reasons.
*sigh* Time to release v0.6.
@Mojavesoft-Group/sparkle-team Because development has been largely-dormant for the past few days now, I am delaying v0.7 until May 20th. I plan on producing an in-between release before May 14th.
Edit: v0.6.1 has been released!!!
I'm having trouble getting Sparkle to work on my laptop (Firefox) so I haven't been able to help much.
Do you have any particular error messages or anything? I'm not much of a Firefox guy myself, but @codingisfun2831t has expressed interest in improving Sparkle's support there.
Mainly for addons, they either do nothing or completely break the editor
What specific addons are you using? Can you send screenshots?
I ran it in firefox, and I think it's stuck somewhere in JSON.parse calls
Huh... odd.
Currently working on something ;~)
@Mojavesoft-Group/sparkle-team Just as an FYI, I'm hoping to release v0.8 by May 27th.
@Mojavesoft-Group/sparkle-team For personal reasons, I am delaying v0.9 until June 3rd at earliest. @e016 Great work on #52!
@sparkle-devs/developers FYI: Sparkle v0.10.0 is scheduled to release on June 10th, one day from now.
@PPPDUD Can you release a new hotfix version? I fixed addonRepoPath as it was linking to Mojave instead of sparkle-devs, which would block it from loading the addons from SparkleMods.
Actually, probably merge #75 first (fixes #73 !) and then make the hotfix release.
Shouldn't GitHub redirect old repo links automatically?
@sparkle-devs/developers Please pause all changes to
index.jsinmainso that #77 can be patched and we can release v0.10.2 with more fixes from me and @codingisfun2831t.Realized the real issue; it was pointing to SparkleMods instead of SparklesAddons which GitHub didn't redirect (doesn't do previous name of repos when doing separate ownership, I think?) but it's fixed now.
Good.