What to test
• Improved code editor stability: Both the old and new code editors should be more stable, please let me know how they feel
• New keyboard accessory for iPhone code editor
• Handle cases where tab bar could overlap code
• Support dark theme in new code editor
@Simeon - installed and checked out both editors, appears fine so far.
@Simeon - couple of things in the examples, first printing up TLL sprite has wrong path for the sprite.
Second in the animation demo throws out an error for techdraw, is this a Tab issue?
Looks like some of the demos could do wit a revamp, I thought someone was working on those.
@Simeon Making changes in the new editor doesn’t seem to take affect until a couple of runs of the code. Made a size change on a sprite and it didn’t change size until I ran and exited the code 5 times. Other times it was 2 or 3 tries.
@Simeon The new editor kind of locked up on me. I couldn’t scroll the code. I could tap the Edit and Do icons and they showed the menus and I could run the code, but I couldn’t scroll the code until I exited and came back in.
@Simeon I’m using the new editor. I deleted a bunch of code, but when I ran the project, the old code was still executing. I exited the project, came back in and the deleted code was still there. Doesn’t seem like the new editor is saving the code correctly.
Thank you for trying it out
@dave1707 it’s not saving code when you run it yet. It’s relying on iOS auto save to save but that doesn’t take into account what happens when you run. I have to fix it as well as recreate all the remaining functionality. The lock up is bad though, that sounds like a race condition to me
@Simeon I was trying some of the Example projects with the new editor. When I was playing the Brickout program, after a short time the screen would freeze for approx 1/2 second every time the ball would do a collision. This was the ball hitting a brick, the side of the screen, or the paddle. The ball and the paddle would stop for approx 1/2 second each collision. I don’t know if that was also happening on a previous version. I tried it again and after about 20 seconds it would do it again. It started with just the sides, then a few hits later the bricks then the paddle.
PS. I tried it with the old editor and it would do the same thing after a short time.
PS. I tried it with 2.6.2 ver 127 and it did the same thing. It might have something to do with the sound command. I noticed in one of my programs the first time sound was played that there was a delay but only the first time.
Interesting bug, you’re totally right about there being a delay the first time the sound was played — Codea used to cache it the first time so that the delay wouldn’t happen in subsequent plays. I’ll look into this.
@Simeon - don’t know if this is meant to happen, but if you text a string at a font size which will exceed the width of the screen then the text does not appear.
fill(255, 252, 0, 255)
font("Georgia-BoldItalic")
fontSize(64)
-- text("tarah",300,300)
text("PLEASE RUN THIS IN LANDSCAPE",300,300)
Try the above in portrait mode, then in comment the first text line. I would have thought the text would print where it could on the screen.
@Bri_G yes that’s a long standing issue in the text renderer which is down to how it renders text. I’d really like to re-write it at some point to not do things the way it does.