Catroid-1623 Refactor GlideToAction to Kotlin

[doppem15]

The following files were refactored and converted to Kotlin by me and simplified as much as possible:
- GlideToAction.kt
- GlideToActionTest.kt
Furthermore, the file "ActionPhysicsFactory.kt" was modified to ensure compatibility with the new Kotlin files.

https://catrobat.atlassian.net/browse/CATROID-1623

Your checklist for this pull request

Please review the contributing guidelines and wiki pages of this repository.

• Include the name of the Jira ticket in the PR’s title
• Include a summary of the changes plus the relevant context
• Choose the proper base branch (develop)
• Confirm that the changes follow the project’s coding guidelines
• Verify that the changes generate no compiler or linter warnings
• Perform a self-review of the changes
• Verify to commit no other files than the intentionally changed ones
• Include reasonable and readable tests verifying the added or changed behavior
• Confirm that new and existing unit tests pass locally
• Check that the commits’ message style matches the project’s guideline
• Stick to the project’s gitflow workflow
• Verify that your changes do not have any conflicts with the base branch
• After the PR, verify that all CI checks have passed
• Post a message in the catroid-stage or catroid-ide Slack channel and ask for a code reviewer

[dajminks]

Hi Markus,

4 suggestions;

1. in ActionPhysicsFactory.kt maybe out of consistency reasons use a setter for duration and scope

2. for easier reading, maybe in GlideToAction.kt Line 85, change the if to check for absolute values to be bigger than 0.1f instead of -0.1f > deltaX || deltaX > 0.1f and same for deltaY

3. If possible, check does the restart (in the update function) work / does the duration really change after the restart

4. You tested for null, Nan and positive numbers, what if you put in negative numbers?

And squash all commits into one commit

BR Dominik

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[doppem15]

Hi Dominik,

i tried to follow your suggestions 2–4!

As for point 1), I understand your argument regarding consistency. However, I believe that in Kotlin it's cleaner to work this way, since set/get are generated automatically and their usage is preferred.
Maybe it would make sense to open a ticket to align this across the codebase — but at the moment, other actions are still written in Java, which is where the inconsistency comes from.