Update UI in nodes-and-scenes

[gianfun]

This PR updates screenshots from the nodes-and-scenes step from the step-by-step guide.

There are two main changes:

• The Create New Node window now specifies the Class much more clearly.
• The Label node has a few extra properties

Questions:

• Are image dimensions important? Should I take care to make them the exact size they were before? (Did not see anything in the guide about this)

Image diffs:

File: getting_started/step_by_step/img/nodes_and_scenes_01_empty_editor.webp

Old:

New:

File: getting_started/step_by_step/img/nodes_and_scenes_03_create_node_window.webp

Old:

New:

File: getting_started/step_by_step/img/nodes_and_scenes_04_create_label_window.webp

Old:

New:

File: getting_started/step_by_step/img/nodes_and_scenes_05_editor_with_label.webp

Old:

New:

File: getting_started/step_by_step/img/nodes_and_scenes_08_hello_world_text.webp

Old:

New:

File: getting_started/step_by_step/img/nodes_and_scenes_10_save_scene_as.webp

Old:

New:

File: getting_started/step_by_step/img/nodes_and_scenes_11_final_result.webp

Old:

New:

File: getting_started/step_by_step/img/nodes_and_scenes_14_select_main_scene.webp

Old:

New:

[tetrapod00]

Looks good!

In the future you don't need to include the images in the PR description. But if you want to take the time, it can help, because GitHub's tools for comparing webp files are really bad

As for width:

• As a rule, new images don't have to match old image dimensions exactly.
• Image width must be less than 1920 pixels (we have a rule that images must be smaller than 1080p, which is 1920x1080)
• UI screenshots should be less than ~796 pixels wide if you can, so that they fit in the content column of the docs with no scaling issues. But this isn't a hard rule and it's not written down anywhere. You can't always make screenshots of the whole editor this small, either.

So overall your images fit the guidelines just fine.

[gianfun]

Cool, thanks!
Yeah, once I realized github would not show the diffs I ended up adding them to the PR description ):

Given the images currently fir the guidelines (and that image 3 and 4 have the same width), I'll leave them as is, then. Thanks!

[skyace65]

I'm going to say no to merging this PR. We're a month or less out from 4.4 and will need to update these screenshots for that anyway because of the new game workspace. In addition you did Lossy compression on these images which we explicitly do not want, and I can see the artifacts from compression.

[gianfun]

Sure, no problem!
I can screenshot and not apply any compression, if it makes sense (so that we have the docs updated until 4.4 launches), but I'm ok with just closing this PR, too!
Or, alternatively, does it make sense building from master and having those images, instead, in order to decrease work for then 4.4 releases?
(If not, feel free to close this PR!)

[tetrapod00]

I think retaking the screenshots, and only targetting 4.4 would be fine.

• No need to build from master, you can use one of the official beta builds: https://godotengine.org/article/dev-snapshot-godot-4-4-beta-2/. I believe since we're in beta we shouldn't be getting any more changes that break screenshots
• Make sure that the original screenshots you're taking are lossless, so either lossless PNG or webp, depending on how you're capturing them originally
• You can compress (and convert from png if necessary) with squoosh. These are the settings I use but I'm not an expert on best practices here. I usually capture in PNG, convert in krita, then squoosh if necessary
  

@skyace65 Does that sound okay, did I miss any steps here?

Should target 4.4 instead

[skyace65]

Tetrapod's instructions are perfect, and those are the squoosh settings I use for my own doc images. So yes if you want you can re-do this PR with screenshots from 4.4. You can either build from master like you said, or use the latest beta from the Godot website, either is fine.

[gianfun]

Updated images using 4.4, but just realized we do not have a 4.4 branch yet. Do I leave it based on master for now and we wait until 4.4 is released?
(I'm going to have lunch but when I come back I'll post the image diffs on the PR description)

[skyace65]

For upcoming releases you just use the master branch. Generally you should always use the master branch except for specific circumstances.

As an example, say 4.4 releases in a month and two weeks later you want to make a PR that applies to 4.4 and the master branch. You would make the PR for the master branch, and we would add a "cherrypick 4.4" label to the PR, so the contents of that PR would be added to the 4.4 branch when we do the next round of cherrypicks.

You would only make a PR for the 4.4 branch, 4.3, etc, if the change you're making applies to that branch but does not apply to the master branch, or if it's a change that was already made to the master branch that can't be cherry picked easily

[tetrapod00]

Overall looks okay to me. This time I checked for lossy artifacts.

[gianfun]

For upcoming releases you just use the master branch. Generally you should always use the master branch except for specific circumstances.

As an example, say 4.4 releases in a month and two weeks later you want to make a PR that applies to 4.4 and the master branch. You would make the PR for the master branch, and we would add a "cherrypick 4.4" label to the PR, so the contents of that PR would be added to the 4.4 branch when we do the next round of cherrypicks.

You would only make a PR for the 4.4 branch, 4.3, etc, if the change you're making applies to that branch but does not apply to the master branch, or if it's a change that was already made to the master branch that can't be cherry picked easily

Oh, I was under the impression that merging to master would publish to the website instantly. Had forgotten that it needs to then be cherry picked to update the 4.3 docs.

Thanks for the explanation!

[skyace65]

Thanks! And congrats on your first merged PR!