I want this box to have a background and border that matches the box to the right of it (and the footer of the page).

Hello Josh:)
I saw your site, and i have noticed that it is in light mode. I think most developer and programmers prefer dark mode. I want to help by creating the dark mode theme and toggle. I have experience in Tailwind and Next.

Hey y'all! After hearing about my little sister's experience using Leopard for the first time, it seems like there are some opportunities to make the end-user experience better. In particular, the translation for her project worked great, but then she was kinda stuck. Immediate roadblocks were:

• How do I publish my Leopard project? (These instructions were too complicated)
• How do I learn JavaScript/how do I make changes?

There are lots of possible solutions centered around creating better educational resources, and I'd like to pursue some of those myself, but there are also some user experience issues that are just fundamentally harder than they need to be. I'm okay with things being hard if it's a necessary difficulty that helps people learn, but if our goal is to be an educational resource to help people transition from Scratch to JS/web development, I think we should remove as many of the unnecessary hurdles as possible.

To that end, I've been experimenting with a custom editor that could be an option alongside the Codesandbox route. (To be honest, I'd like to have lots of export targets, such as Replit, Codepen, a simple .zip, etc, with this custom editor being just one of them–albeit maybe the default one if it becomes good enough at some point in the future.)

My goal with the design is to be a fully-featured editor which allows users to edit any static website any way they want. However, I also want the editor to be extremely reminiscent of the Scratch editor. For that reason, rather than exposing the files as a simple file tree on the left, I'm putting the top-level folder in the bottom right as a grid of icons (which essentially serves as a "sprite picker" for conventionally-organized Leopard projects), exposing the contents of the selected folder as a list of tabs, and then if you choose a tab that is a folder (such as "costumes" or "sounds"), exposing the contents of that directory as a file tree on the left–equivalent to the list of costumes/sounds in Scratch.

In all, this allows users to organize their files in any way they want, because it's just a file system, but to get the full Scratch editor feeling along the way.

Custom blocks are weird when comparing their json to other blocks and i hate it >=(

One option would be to use Scratch's paint editor. Another would be to find some other open-source editor to use. It does not make sense to build our own.

cc @towerofnix, @adroitwhiz, @sfederici, @HanClinto, etc because I want your feedback and I suspect that you are not subscribed to this repo.

I am just about ready to share a hosted super-duper-alpha version of the Scratch-style code editor for community feedback. I'm really excited about it! But expanding the scope of the website has also got me thinking a little bit about the new responsibilities that such an expansion will create, and I want to make sure we're all on the same page about those.

This is important to me because the website is a hosted, centralized thing, which doesn't lend itself to the same free-for-all contributions that our open source libraries do. Unlike leopard and sb-edit, the website has some centralized responsibilities:

• Expenses (domain, hosting, database, and with the new editor also uploaded assets)
• Legal liabilities (terms of service, COPPA, etc.)
• Moderation responsibility (social sharing will be extremely limited, at least at first, but there's still a lot of due diligence required when you allow users to upload arbitrary assets)

I am more than happy to be personally on the hook for paying all the website expenses, upholding legal responsibilities, etc. But I've realized that–unlike the open-source libraries, where I want to be a contributor/community member that is equal to everyone else–I only feel comfortable putting myself on the hook for the website management if we all are on board with me also having the final say on matters of website decision-making.

So here's my proposal for how I think things should be organized. This isn't any different than how things have already been. I just want to be completely clear and make sure we're all on the same page before the website begins to take a larger role in the Leopard ecosystem.

1. The leopard and sb-edit packages are fully community-driven. The process of designing and implementing new features & publishing new releases is as decentralized and democratic as we can practically achieve.
2. The leopard-website is community-inspired, but the responsibility for managing it falls on my shoulders. I pay the expenses, I own the website, any issues are directed at me. I will gladly incorporate ideas and contributions from others (more community is better!), but because all the liability is mine, I also get the final say in website-related decision making.

Again, this isn't really any different than what we've been doing so far. But I think now is the appropriate time to clarify the roles and responsibilities so that there isn't any confusion down the line.

I am incredibly grateful to everyone here who contributes to Leopard in big ways and small, and I want to make sure I'm doing right by you. The two bullet points above outline a community structure that feels healthiest to me, and that makes me feel safe taking on the website responsibilities with the new editor. But I want your feedback. Does this seem reasonable? Are there alternative structures that you believe would be more fair or lead to a better future for Leopard?

Thanks,
Josh

See this Cleanup Crew discussion: leopard-js/leopard-mentors#7

Then I noticed that Leopard sprites are folders, so I tried to add a new folder. I gave it a name, but when I press enter or click outside the name box the folder disappears.

REVISION: the folder does not disappear. It just moves before the Stage folder. That is misleading to me. If we don't want to mix sprites and stage, maybe the stage could be placed as the first element of the Project Files area, so that when the new sprite folder name is confirmed the sprite doesn't move around?

Now the "Project Files" list is really just a view of the top level of hierarchy, so I understand sorting it the same way as other views (folders first, alphabetic, then files, alphabetic)... but since it is analogous to Scratch's sprite list, it should come close to its behavior :)

Right now it is confusing that when you create a new sprite (folder), the input to enter its name appears at the end of the list, but after you press enter, gets sorted somewhere "magically" into alphabetical position. Most of the time (citation needed) this is before "Stage" and that causes confusion, because you appeared to be making a folder that would appear after "Stage".

I think we might want to drop the automatic alphabetization in the first place and just let users drag and drop to change the order of their folders, like in Scratch. But apart from that, a much simpler fix would be to just move the "Stage" folder to always appear at the start or end of the list, as @sfederici suggests in the linked cleanup crew discussion.

I haven't read the announcement in detail yet, but we need to make sure this won't break anything: https://www.codesandbox.community/c/api-billing-updates/api-update-and-usage-based-billing

It is currently a bit tricky to create a new sprite, because you have to understand that "costumes" and "sounds" are not just magical tabs that sit on the top of the code/costumes/sounds area (like Scratch), but actually folders themselves. The folder icon probably helps, but there's still some confusion about it, as seen in leopard-js/leopard-mentors#7.

I think it would assist new users, and be convenient for experienced users, to have a "Sprite" button under the Project Files' "Create" menu. It would probably require you to choose the first costume, because sprites need at least one costume to function properly, and give it a name. (I don't know the best user interface for getting both of these - and they are both needed, to set up a sprite!)

Then it would create the sprite folder, its "costumes" and "sounds" folders, its JavaScript file, and - ideally - add the JavaScript code that actually initializes the sprite into the Stage folder.

Of course, this probably needs a bunch of workshopping to really become useful and feel right lol, but I wanted to bring it up as a point that might be important for helping users get started making their own projects in the Leopard editor.

Mainly, I want to remember that because the Leopard editor provides abstractions over the actual file system structure of the project, it should also provide tools to ease interacting with those abstractions. If it looks like the Scratch editor, it should basically work like the Scratch editor, or as close as we can get without hurting Leopard's own capabilities. The Leopard editor shouldn't just be a "skin" over a normal hierarchy-based code IDE, you know?

sb-edit requires pushing to this repository before it goes live on the website, so sometimes the version most users access is outdated. It would be handy to indicate the current version of sb-edit, especially when there is a project translation error.

As both links or SB3 files, you can NOT upload big projects like paper minecraft to convert to JS or it will load forever. I get these errors in console

Patch or help appreciated!

I neglected scratch-js for a while, but I have time now! 🎉

I'm planning to do an advertising push to make sure everybody knows about scratch-js, but first the whole project needs a bit more polish.

The final important job before really publicizing scratch-js is making it easy to edit and share projects. There are a few options here:

• ✔️ Glitch: Strongest community and most Scratch-like vibes.
• ❌ Codepen: Free-tier users are limited to one project.
• ❌ CodeSandbox: Very little community focus. Sharing projects isn't really a thing.
• Any other recommendations?

The problem is that Glitch doesn't have an API for making projects. I'm hoping that it's possible to hijack the "import from Github" process by serving projects as read-only git repos on the scratch-js website.

Here I've highlighted that error message, so you can see it:

If you don't highlight it (e.g. because you think the project is still loading), you'll only see a black stage area!

Well there is, on the main homepage that is — but nowhere else!

Footers are sort of how we personally get our bearing on any website, and I think this especially goes for people who are acquainted with Scratch. The Scratch footer is very crowded (compare it to GitHub for example), but I think it would aid familiarity to incorporate some sort of footer. Even just a dimmed out Leopard logo (that takes you to the homepage) would be cute and nice for visually cueing the end of a page, lol

Looks like something's not lining up here:

Safari 17.4.1. The scrollable overflow is present regardless of window dimensions and regardless whether scrollbars are set to show always (above) or only when scrolling.

Help users write code by providing Monaco autocomplete options based on Leopard's .d.ts file. This is something that I thought would be easy in the past but turned out to be surprisingly hard. Still, it's super important to having a productive development environment.

In an ideal world we would load .d.ts files associated with any URL import in your project, but if it's easier to provide specific support for only the Leopard page loaded from unpkg, that gets us 90% of the benefit.

It's not clear that something is happening when you click the green flag. Add an indicator of some kind to make this obvious.

Per @sfederici: https://scratch.mit.edu/projects/1043871984/#comments-412442742

"If I stop a project, the Stage goes blank. If I restart it, it takes a little while and in the meantime the stage is blank. So, the first time, I kept clicking the green flag (restarting each time the 'blank time'). I guess an 'hourglass' or similar would help"

On desktop it gets too narrow to read comfortably and the title bars stop fitting the title text:

On mobile it's hardly legible:

It would be nice to have a way to generate a standalone zip of a project converted to Leopard. Preferably, this package would work without internet access; I've already implemented an option to include reference Leopard library files packaged locally rather than online.

We might want to show a brief modal describing how to work on the project locally (like opening source files in a text editor and using the terminal to cd to the project directory and run a simple HTTP server), especially if we implement TypeScript integration (basic familiarization with npm install and npm start commands, maybe an npm build command for standalone all-in-one "My Project.html" type export).

• Show user count
• Show email verification status on user list
• Show counts of shared, unshared, and anonymous projects, as well as total

This can get pretty annoying, especially when the project uses the arrows keys.

Add a new project button to the my stuff page. It's nice to have on the homepage, but should exist in my stuff as well.

I used https://scratch.mit.edu/projects/435452534 but it didn't work.

And, more generally, better documentation on how to run the website yourself. Especially locally, so that others can contribute to the website.

As pointed out by atKingNC, TurboWarp embeds certain settings (like custom stage size, infninite clones, remove fencing, etc.) into the project JSON. In theory, these settings could be preserved and forwarded on to the Leopard output when a project is uploaded via .sb3. (Of course, these settings won't exist in project files on the Scratch website.)

Especially because the nav bar is mostly a similar color as the main page and content areas (to be clear: we love its appearance!), it doesn't pop very much against the content it is covering up. Try comparing these two screenshots below and at full size:

The box-shadow in this demo is 0 0 2px 1px #00000060 — this could be adjusted to anyone's liking, of course, but the main point is to more visibly delineate the end of the nav bar and the start of content, especially when scrolling down.

Right now the profile contains four things:

1. Profile picture
2. Username
3. Join date
4. Project count and list (incl. project names and dates)

The "Projects" header looks like a tab switcher, so perhaps other sections to do with user creations, content, or connections are planned.

There's nowhere for a user to describe or introduce themselves yet. The layout sort of reminds us of GitHub — maybe a short user-written blurb beneath the essential info? GitHub also supports "profile readmes" which are a more detailed intro space, and show at the top of the page.

Scratch divides the profile into several narrow-ish rows before the comment section. Most of the first row, which is the tallest, is customizable: two blurbs are "About me" and "What I'm working on" and a "Featured Project" section shows a thumbnail of the user's latest project or one of their choice, and can have its label adjusted.

I think we're going to reach our account storage limit pretty quickly, since we can't seem to toss away the projects it turns out we don't need 📦

The sidebar help, under "How can I get more storage?", tells what to do "If you've run out of storage space and do not wish to delete any projects"... but I don't see a button in My Stuff, on the project page, or in the project editor, to decide to trash or permanently discard this project.

When the block translations table is open, move the dialog up accordingly.

Projects created from a template are known to be working correctly. So keep the "Project not working?" popup minimized when the page first loads.

Loading project previews was opening too many database connections, so I set up Prisma Accelerate because it is the recommended connection pooling option by prisma.

This is working for now, and is a good solution at least temporarily, but I don't love it. Mainly for cost & vendor lock-in reasons, but also because it complicates our setup and adds an extra point of failure.

Other possibilities include:

1. Find an alternative connection pooling option. AWS provides their own, which might pair well with our Amazon RDS database, except it doesn't work with Prisma "due to the way RDS Proxy pins connections" (source). Maybe there are more good options out there, but it feels like we're still going to be locked into an additional piece of infrastructure that we have to pay for.
2. Move away from Prisma. Something like RDS Proxy might work if we weren't using Prisma. (I haven't done the research to know for sure.) Drizzle ORM is currently in vogue, but I haven't used it personally. I'd rather not make the switch if we don't have to... it feels like a bunch of rewrite work for little benefit, since Prisma has been good enough so far.
3. Move to a "serverless" Postgresql host like Neon which allows millions of simultaneous connections to a Postges database. The downside here is that BXCoding is providing us with free AWS credits for the year because they had access to extra. It would be a shame to move away from AWS for database hosting.
4. Move away from serverless. (This would prevent the constant closing and re-opening of database connections.) Instead of hosting on Vercel, we could get a $5/month DigitalOcean droplet or something. (BX Coding is providing us with free AWS credits for this year so there's probably a droplet equivalent available from Amazon. I'd have to look.) Migrating shouldn't be too hard since Next.js can just run as a regular Node app.
5. Host the project previews separately from the website & editor. The preview just needs to hit the database to match each path to a file and then serve that file. Maybe there's some alternative way of serving the preview separate from our Next.js project that would allow us to keep everything else the same.

Hey Josh
so excited to get my game onto Vercel.
My game works OK on the Scratch site but crashes on https://leopardjs.now.sh/
Any hints ??
Here 'tis
https://scratch.mit.edu/projects/490285759/
Where to from here?
cheers
Rob

https://scratch.mit.edu/discuss/topic/420162/?page=53#post-8037209

Potential bug? I can't register an account in brave browser, as the birthday month field resets everytime I click away from it. I can set a date just fine, but clicking anywhere (including the register button) clears it again. Also, the current format is “January 2000”, while below the box it says that the format should be “YYYY-MM”.

Using Firefox, the Format is correct, where it's YYYY-MM, but typing in 1998-04 for example, always deletes the “0” after clicking away, which makes me unable to register.

https://scratch.mit.edu/projects/1043871984/#comments-412442313

"if I register with my month "02" it automatically goes to "2" and doesn't accept it" [...] I'm using Firefox in macOS

Requested by Thebro57 on Scratch: https://scratch.mit.edu/projects/1043871984/#comments-413169206

My only real problem is there's no debug tab for errors from the console. Without those errors, I have literally no idea why projects won't run. I would probably place a debug tab as a switchable tab with the sprite "folder" selection menu.

I think this is a great idea and will probably implement it exactly as described.

It seems like console-feed is the best package for embedding a Chromium-style console into the page: https://www.npmjs.com/package/console-feed

Here's the layout for the editor tabs, running Safari 17.4.1:

Pink lines are the main flex-direction: row container, blue/cyan lines are the "Create" button - which really is that wide.

Possibly flex-shrink or flex-basis is needed on the create button? Here's the same view if we add flex-basis: 200px:

Keep CodeSandbox and .zip options, but switch to Leopard Editor by default.

I think this should be a very strong default (possibly even the only option for now). Particularly for beginners, opinionated code formatting helps a lot.

When I try to upload an SB3 the website just gets stuck forever uploading and makes no progress. Any thoughts?

...but for some reason it isn't, even though the latest version of sb-edit specifically includes it?

https://scratch.mit.edu/discuss/topic/420162/?page=18#post-5532550

In the index.js file of the translated project, it should say something like...

const project = new Project(stage, sprites, {
  frameRate: 30 // Set to 60 to make your project run faster
});

But instead it says const project = new Project(stage, sprites); and I genuinely have no idea why. 🤔