A tester really struggled with this practice. Like for lesson 4, we should start with a simpler practice as students first get to use their own function parameters here. See #30 for more information

For cases where the server takes time to respond, it’d be nice to show some reaction and suggest stuff is happening

Lessons consist of multiple "content blocks", which can be a text section or a quiz (so far). It seems reasonable to me that students may want to mark some sections for future study/revisiting and be able to quickly navigate to those. They can do it already with browser bookmarks, but it would be better to have it built-in into the app itself for consistency.

It should be trivial to bookmark content blocks, and we can even implement an automatic bookmark for the last section you've viewed in the lesson to go with #43 and to address #39 in a graceful way.

When giving the right answer, the quizz panel pops instantly. It’d be nice to animate the height. We could also animate the panel when showing a hint, see Consider adding optional hint to quizzes

To grab the user’s attention and make it clear when some check(s) failed

From backer's comments:

I've completed the first lesson Practice, and I don't like that it pushes me out of the lesson as soon as I press Play. I wanted to close the Well done! dialog and review the execution status of the program (in particular, whether the print("Welcome!") line had been printed to the Output console), but the "Got it!" button closes the environment and I need to navigate back to the lesson and re-read the full text and answer all the quizzes to access the practice environment again.

And they have a point. So I think we could just add a button to close the popup and remain in the practice, while still tracking that practice as completed. We can maybe even add another button to the bottom of the practice screen itself to go to the next practice/lesson that is unlocked after you complete it once.

Posting links to the app on social media should look better

Students can back out of the practice screen using either the back button or the outliner/index button. We don’t warn about leaving whatsoever, but students may have some unfinished code there and the click on a button might have been a mistake.

It stands to reason, we should warn users before they navigate away and lose any progress, at least if there was some progress (i.e. the code in the code editor is different from the default slice.

I wrote an assignment where the student has to define a variable and give it a specific starting value. On the first run, if you just assign any value to a var, the test “health is equal to 100” passes although it shouldn’t.
This happens if you write anything like var healthvar health = 5 etc. From the second Run, though, the tests work as expected. The test code is:

var health_value = first_node.get("health")
if health_value == 100:  return ""

If the student doesn’t write the property, the value should be null and cause the test to fail, but it doesn’t.

It would make sense to give more in-lesson navigation options for quick scrolling through the content. This also goes in hand with the addition of optional headers for content block (#19). We can also indicate quizzes on the TOC.

Additionally, it can help to address some concerns raised in #39 by adding a bookmark label that would scroll you to the last known position if you've visited the lesson before. It would also feature a "back-to-top" button.

If a game uses a common class, and this class defines a slice, this slice will not be seen nor exported.

If we'd extend the exporter to look into what file a class extends, then we'd run into a different run-time problem: how to replace the base of running scripts (we probably need to re-write all of them).

For the moment, I'll just leave this as unresolved, but we should either find a solution to it, or make it clear in the documentation

Describe the bug
The "Draw A Rectangle" practice freezes application when run.

To Reproduce
Steps to reproduce the bug:

1. Go to Drawing A Rectangle
2. Fill out parameters for functions, "Too few argument exceptions" work correctly.
3. Hit Run
4. Application freeze.

Expected behavior
GdQuestBoy makes a lovely rectangle

Screenshots
https://user-images.githubusercontent.com/7501092/147651163-b7f7829f-fc61-46b9-a0f2-e6261effebfb.mp4

Information about your device (please complete the following information):
Windows 10, Firefox

Additional context
After a browser refresh, run doesn't pick up any exceptions or seemingly do anything. Need to go to another pracice and back again to start from step 1 of the reproduce steps.

Quiz answers are buttons, and when they’re long or when the user select one, they can get wider than the UILesson column. Especially with larger font sizes.

We should either code custom buttons or find another way to make the text wrap in there. See the last quiz of lesson 3 for an example.

Many neophytes work primarily with the mouse. Coding can be tedious if you don’t use the keyboard and shortcuts like Ctrl backspace. We could include an interactive tutorial (or mini-game) to learn and practice the most important shortcuts :

• Copy, cut, and paste.
• Ctrl backspace.
• Selection with Shift and arrows.
• Selection with Ctrl Shift and arrows.
• Using Home, End, Ctrl Home, and Ctrl End ?

When users report a typo, it’s currently difficult to find. It’d be great to have a text search field to jump to matches in content blocks.

We're using a custom HTML shell now, so might as well have a proper placeholder

Currently they use a plain revealer and don’t really stand out. The idea with those blocks was to have them folded by default as they provide info that goes beyond the lesson. But they could use a better presentation.

Describe the bug
If you open the course index while in a lesson, then you can't go back to where you were. If you click the icon that replaces it (still says "course index" in tooltip) you go back to the "main screen" - which is unintuitive.

Lesson 1: What Code is Like
The tutorial should run the user through using the practice interface
Lesson 2: Your first error
The tutorial should explain how errors work and how to fix an error to pass a practice

See the textures on dropbox

Godot consumes input when in focus, preventing you from using the toggle full-screen shortcut of your browser. We should add a button (and optionally a shortcut) to toggle the app full-screen.

The separator could add a separation line and some bottom margin (an HSeparator node?)
We need an option in the Course Builder to add this to content blocks

Creating a square from the get-go in lesson 4 is a bit difficult. We should consider a simpler practice first : creating half a square with a call to move_forward(), turn_right(), and move_forward().

This would illustrate how turn_right() works and make it clear to the student.

Describe the bug
When you're in a "practice" you should be able to run the code without having to move your mouse. I expected to be able to use Ctrl+Enter to run the code, but it does not run.

Some content blocks like spoilers and notes could use a special heading displayed on the revealer.
In other cases, we have to use special bbcode to insert section headings: [font=res://ui/theme/fonts/font_title.tres]Some font[/font]

When the student fails to find the right answer to a quizz, we could display an optional hint to help them (and nudge them towards trying again and succeeding over skipping).

It can be a bit difficult to get the blue bar to insert a new block to appear. I often have to wiggle my mouse a bit to get it to show up

This makes it easier for students to know where they are in the course. Also, this way, they can report content issues more easily.

Even if we include tutorials, we should have a place for students to remind themselves of how to use the app and see keyboard shortcuts.

Things like :

• How to reset progression
• How the practice screen works
• What shortcuts are available

Etc.

When making changes to the project, we can break existing assignments. It’s easy for a contributor or teammate to miss a little thing and cause something not to work.

To help ensure things work as intended, I’d like to have a test we can run to ensure every practice still works.

Tests we need:

• For each practice, applying the provided solution and running passes all checks successfully

How to test practices

You can create an instance of UIPractice.tscn and provide a practice resource to its test_practice property before adding the UIPRactice instance to the tree to test a practice in isolation.

To get the practice resources, load res://course/course-learn-gdscript.tres and loop over the lessons, then, in the lessons, you'll find a practices array containing the required resources.

The simplest way to test right now would be to do UI automation:

• Press the solution button
• press the use solution button
• press the run button

This will call the function _test_student_code(), which sets the property _practice_completed to true if the practice passed. There is a signal emitted in this function, but it is only to give the student a checkmark if they completed the practice without using the solution. You could add a new signal at the end of the function to know when to check the _practice_completed property. It should be true if the solution code works.

There was a bug causing hints to overflow their container, fixed in 6e3216677565bb5f4047753ff6b947d363539a30There were issues with the RichTextLabel in PracticeHint calculating its height too early, and RichTextLabel.get_content_height() being unreliable, so as the panel it’s in has a fixed width, I just gave it a fixed width from the get-go.If we’re going to resize the parent panel, this will break a bit. So we should figure out a way to make it work reliably.I think a solution would be to instantiate the RichTextLabel from GDScript and defer adding it as a child of the PracticeHint revealer until we have the revealer’s width set by its parent. That way, the Fit Content height feature of the RichTextLabel should instantly work.

Consider adding an interactive glossary (explaining keywords on hover).
To remind the meaning of keywords like functions, variables, loops, the game loop, etc.
We could try to smartly match terms in the glossary. For example, a function parameter or a function argument is the same thing. We may also pluralize them in the text or use -ing forms (”function call”, “call functions”, “calling functions”, etc.).
That should work both in lesson and practice views

Tasks:

• Add glossary as CSV
• Detect glossary terms in content and display popup on hover - lesson and practice views
• Consider doing that only for first occurrence of a term? Double-check that with repetitions, some terms won't have too many highlights
• Translation support - create new .po file from CSV

I'm submitting a...

• Bug report.
• Feature request.

Bug report

What is the current behavior?
Run the turtle examples second time draw outside rectangle.

What is the expected behavior?
Turtle examples draw inside rectangle when you click second time on the run button.

Tell us the steps to reproduce the bug, and if possible share a minimal demo of the problem.
Click twice on the run button with turtle code snippet.

During exercise "drawing a rectangle", when I press "run" button after setting the correct parameters app crash and i must refresh the page.

To Reproduce

1. Go to https://gdquest.github.io/learn-gdscript/#course/lesson-4-drawing-a-rectangle/practice-5AJTESv5.tres
2. set functions param
3. Click on 'run'

• Limit maximum size on large displays
• Add nicer loading bar
• Change the background color
• Make the app full screen when making the browser full screen

Describe the bug
This is an issue (I believe) specific to Qutebrowser.
Text input field (where you edit code) isn't focused automatically on mousepress like you would expect.
Qutebrowser users need to manually enter "Insert mode" to be able to edit the code. This effectively means you need to type "i" to edit code every time you focus away from the text box (like pressing "run" or clicking somewhere else).

To Reproduce
Steps to reproduce the bug:

1. Run demo in Qutebrowser

Expected behavior
I expected my browser to automatically enter Insert mode, like it does in every other input field when I click it.

Information about your device (please complete the following information):

• Operating System: Linux
• Browser qutebrowser v2.4.0 (QtWebEngine 5.15.7, based on Chromium 87.0.4280.144)

Additional context
This is probably qutebrowser specific issue, I don't expect much here. It's just annoying.

Related to issue #42, which was fixed with a workaround.

DrawingTurtle.Polygon is inconsistent; the points property is an Array, but because of legacy code, when points are assigned, they are cast to a PoolVector2Array.

This crashes Godot in release mode, and is referenced by godotengine/godot#48090

To fix properly, we should either:

• Remove the cast

or

• Change the property to a PoolVector2Array, and verify if there are other changes needed where it is used.

In both cases, once done, the workaround in commit 3a78bd5 should be reverted

When increasing the font size, the code listings can start to lack width and the code tends to wrap a lot. The UILesson column is only ~700px wide, so we could increase the width a bit with the font size to avoid this issue (and somewhat preserve the layout).

Right now, even if the student uses the provided solution, when they run the practice, we mark it as complete.

Like we did with quizzes, if they use the solution, we should leave it as not completed.

Changing the quizz type causes the creation of a new quizz resource and loss of the answers.

We need to dump the content of all course resources to text documents or something. Ideally po files.
Our i18n program can convert text files to .po files, so we could just convert lessons etc. to text files.
Godot supports .po files natively and for an efficient translation workflow (pro stuff) it’s more efficient than using CSV (pro translation programs work with formats like .po).
We need to figure out how to handle translation keys.
Translations should also work for the GDScript errors, using their simple keys

The reset button only resets the code right now. A tester was clicking it expecting it to reset everything. Another possibility, instead of this task, would be to add a tooltip or clarify the button label (reset code instead of reset).

Calls to turn_right() or turn_left() work but don’t make the turtle turn visually. Animating the turn on generated vertices would make it easier for students to understand what the function does (the turtle virtually turns in place but does not draw anything).

With this change, when the turtle reaches a vertex, it would turn in-place based on calls to turn_right() and turn_left().

For an example of the issue, see the runnable example in lesson 5 that only draws one line.

Calls to turn_right() or turn_left() work but don’t make the turtle turn visually. Animating the turn on generated vertices would make it easier for students to understand what the function does (the turtle virtually turns in place but does not draw anything).

With this change, when the turtle reaches a vertex, it would turn in-place based on calls to turn_right() and turn_left().

For an example of the issue, see the runnable example in lesson 5 that only draws one line.

When running the code, if the server never responds, the app will stay frozen. We should add some kind of timeout unlocking the app. Ideally, we could then check and tell if the server is down or something.