HTML-Fan wrote:

--Explosion-- wrote:

who have read all the documentation.

Documentation?

Basically a language book. In a programming sense, it's where they stick everything that you can do with the language/library. For example, if you need to figure out the contents of the Lua string library, you would pop over to Lua's documentation and there you go: every detail of Lua's string library. It'll tell you what methods you can use, what arguments to pass with them, what constants you can manipulate, etc.

Oh, and where can I find that?

HTML-Fan wrote:

Oh, and where can I find that?

The documentation of what? Lua is at: https://www.lua.org/docs.html

The scratch documentation.

HTML-Fan wrote:

The scratch documentation.

For the source code, I have no idea. Each repo has its own readme. You should probably explore those for the dependencies you'll need to read up on.

There isn't much to read.

HTML-Fan wrote:

There isn't much to read.

Oh there is. They are linking all sorts of stuff: ReactJs, Node, some libraries (e.g. Jest).

The readme here is rather unspectacular.

HTML-Fan wrote:

The readme here is rather unspectacular.

Well that's what I said: I have no idea. The readmes might be a good place to start, but honestly don't expect any kind of directory: the Scratch Team probably know by heart where everything is.

That's the thing: The scratch team does. While working on my own code, I can also tell you on which document at about which height a function is. But noone else can.

HTML-Fan wrote:

That's the thing: The scratch team does. While working on my own code, I can also tell you on which document at about which height a function is. But noone else can.

I already supported the suggestion for a brief directory.

And that's not quite right. The only people who could tell you everything about the code would be those who have read it, regardless of who made the script in the first place.

Why not start diving in to the root libraries right now? Though it would be nice, the ST don't have to be the ones to do it.

Editing Scratch and creating derivatives should require a certain degree of proficiency. If we get tons of low quality stuff, imagine how much Scratch's reputation would suffer. If you can't do it, perhaps this isn't the thing meant for you.

Okay, currently I'm looking at the source code. And here are dozens of directorys with small parts of scratch in it. For example, the green flag has its own directory with some JS and an svg in it. I would really like to have a PDF showing the scratch editor and there are the different parts of scratch (like the green flag) highlighted including the file name of the stuff which produces that part, like the green flag. That would make it much easier. I don't want to read > 10000 lines just to find where the block colors are stored.

So, here's a mockup how a programm could help finding the files which create certain parts of the editor.

ResExsention wrote:

--Explosion-- wrote:

LastContinue

They're gone.

Noooo!!! They were like a really amazing non-scratch coder though I think. RIP LastContinue, god of coders lol

ResExtension wrote:

--Explosion-- wrote:

wut iz goog
It would be helpful to have some documentation though, but as ResExtension said, sometimes you need to read EVERYTHING to understand one part.

O_O

o_O

And my poor mockup?

HTML-Fan wrote:

So, here's a mockup how a programm could help finding the files which create certain parts of the editor.

HTML-Fan wrote:

--Explosion-- wrote:

who have read all the documentation.

Documentation?

Well, there's some stuff on the wiki for each of the repositories, and there's also the readme.md. Anyways to get to the wikis do this:
https://github.com/llk/[repo name, e.g. ‘scratch-gui’]/wiki

--Explosion-- wrote:

Well, there's some stuff on the wiki for each of the repositories, and there's also the readme.md. Anyways to get to the wikis do this:
https://github.com/llk/[repo name, e.g. ‘scratch-gui’]/wiki

That's just this.

HTML-Fan wrote:

And now I don't understand everything, but I know how the graphics part of the lib works. That's enough for me.

Right, it's quite fine if you don't know the meaning of each of the folders in the Scratch source code. Furthermore, an abstraction, which could be a variable, procedure, data type, or programming language, can be used in such a way which is independant of how it works. (For example, you can learn to ride a bike without knowing how its drivetrain works, and likewise a new Scratcher has little trouble employing MOVE STEPS.) “goog” means the Google Closure Library; what follows indicates what part of Closure is being used. It's not hard to figure out how to use goog.array.remove or goog.math.Coordinate when you come across it in the Scratch source code. Similarly, if you notice that you're reading the constructor for a block, it's not hard to notice that once a new block is created it fires a BlockCreate event, without reading Blockly.Event.

Because good code is self-documenting, the names of folders and source files should be mostly sufficient to find which source file to edit. (Supposing you meant the sprite info panel, there are only two folders in src which sound all that pertinent: containers and components. The relevant source code is in src/containers/sprite-info.jsx and src/components/sprite-info/sprite-info.jsx. Maybe “src”, which is an abbreviation of “source”, is a bit unhelpful, but it's very widespread.)

The built-in Scratch extensions belong in scratch-vm/src/extensions. Here's a tutorial which explains how to make a Scratch extension, and here's a mod by Sheep_maker which allows one to load arbitrary extensions.

Oh, you're awesome! These links! Scratch is pretty easy to use even the JS code. At least adding extensions.

But where is this terminal to execute git commands?