Here we are again: Sometimes it´s there, sometimes it´s not... 
eNeuer Text sldkfjasldfjaslf
Language: German
No plugins
The effect doesn´t occur if you exit the textbox by clicking...
Ok, I think, I´ve found something: The effect only occurs (at the moment 
), if I enter the textbox via a self defined shortcut (option-command-e). If I enter via pencil everything is fine...
Thanks for the video and additional information! It helps, but I still can't quite reproduce it even if I set my keyboard layout/system to German and try modifying the keyboard shortcut.
From what you sent, it looks like the web view must somehow be capturing part of the keyboard shortcut and trying to make a letter out of it. What you pasted in had an 'e' at the front (and reads as ascii...) though clearly something else must be going on.
To try to figure it out more, can you:
- Let me know exactly what (physical) keyboard you are typing on
- Reproduce the bug and send me a zip of the .hype document (so I can better inspect what the actual character is)
- Command-Option-E is the default shortcut for Edit Element's Inner HTML. It sounded like you were using this in the system preferences as an override (probably from when we didn't have this shortcut?). If you remove this and/or change it, does it make a difference?
Hopefully we can get to the bottom of this... thanks!
@Djon are you able to reliably reproduce it now in watching @ktewes's steps? Or did it fully go away for you?
... the standard keyboard of my MacBook Pro M3
Command-Option-E is the default shortcut for Edit Element's Inner HTML. It sounded like you were using this in the system preferences as an override (probably from when we didn't have this shortcut?). If you remove this and/or change it, does it make a difference?
No, I just thought I would still use my own shortcut, which I indeed did in the past. Currently no system shortcut - the bug occurs when using the Hype shortcut.
test_kt.hype.zip (13.5 KB)
Well that is odd. When I opened your test I could see the square.
I got the same issue with your doc. I then opened a new doc and did the option +.cmd + e on it added some text and then hit escape. Bang got the issue.
I was not getting the issue until then.
I quit reluanched and opened a new doc tried again. Back to normal.
Copying your text into terminal gives me this.
But not sure if what we are seeing is another un resolved ascii expression.
One thing I have noticed but not sure if this always happened was the cursor would jump to the start of the text and blink non and off. waiting for me to type!.
I just did the update to 14.4.1 - what can I say - the bug is gone. The question is, why and for how long... I've had this effect once before after a system update - the bug was gone, but then reappeared later... 
defaults write com.tumult.Hype4 useWebKitGraphicsAccelerationForSceneEditor -bool NO
That seems to help! 
Can't reproduce anymore. Everything is normal for now.
Thanks for sending the file, that was very interesting. The character being inserted is 0x1B, which is the ESC character code. There's just really no reason I can think of that a text view should ever allow for a code; perhaps there's something about the interaction of using the keyboard to show the window that puts it in a half-done state where it is expecting to type something and then blindly accepts this in some weird condition. I still can't even reproduce it myself, but I did add one extra safeguard in code that I'm hoping will at least prevent this specific bug.
Along with that possible fix, I also made a targeted fix for the original issue with the element not being displayed. I'd appreciate if everyone here could:
- Remove the defaults that had workarounds for these issues via:
defaults delete com.tumult.Hype4 useWebKitGraphicsAccelerationForSceneEditor - Download a new build of Hype v4.1.17 from:
http://tumult.com/hype/download/Hype-760.dmg
That download is a real/non-beta build but I just haven't made it a public upgrade yet... so if the fix looks good it would become the official release.
Thank you so much for reporting and helping investigate/debug these!
Thanks, Jonathan. I'm now on vacation. Will test it immediately afterwards.
1 Like
I have done all the updates. Cannot see that text issue going on any more, even with the above test file.
The issue I had with the wrong folder name in the save dialogue still persists though!.
I am not getting it with any other apps including Whisk.
For example The last saved folder was a folder named test
As you can see here we are led to believe that we are saving in the Documents folder.
But in fact we are in the test folder.
Hmmm... Do you mind sending me an entire screen capture that shows the whole process from the start of launching Hype to doing a save as that shows the wrong folder? I tried a little but can't reproduce -- unclear if it is my steps being different.
Can you please also let me know:
- what version of macOS you are running
- the values of system settings > desktop > dock > windows > ask to keep changes when closing documents and closewindows when quitting an application.
- If you ever set any preferences or have any apps that might modify the save dialog or folders
Thanks!
Sent you a video.
I figured out while recording the video what is going on.
The issue is happening when the folder being saved to, is in the iCloud Drive.
It works as expected when the save folder is in a normal directory.
From what I can see so far, other apps are working as expected even when saving to iCloud Drive , including Whisk.app
Forgot to add on the email. macOS 14.4.1 (M1 MacBook Pro )
In regard to graphical issues, I got this yesterday when going from the Scene editor to a the function editor.
I was not doing anything special. This persisted while moving between scene and function editors until I quit and relaunched.
As you can see the Rule from the scene is showing in the function editor.
1 Like
Thanks - I got it and can reproduce the problem. It looks like if you save into iCloud drive, it won't properly show that path in the popup the next time you show a save panel. Likewise I can't reproduce with other apps, so this is very bizarre. I'll need to look into this further.
Hmm, I think I've seen this once or twice but have never been able to track down what might be causing it. If you find it happens again can you let me know what you were doing just before you saw it? Thanks!
1 Like
Will do.
1 Like
Just got this glitch. Which is what I have been seeing before.
But this time simply switching to a new scene (added a temp one ) or going into a function did not fix it. Only closing the doc and reopening it did.
I had two rects inside a symbol. I had moved the blue rect offset to the right of the symbol frame but then decided I did not need it, so deleted it off the scene.
The green rectangle then jumped down to the right - down offset of its actual framed bounds.
This image is after I exited the symbol to see if things would jump back. they did not.
Doing an undo put the blue rectangle back but also offset from its actual framed bounds. shown here.
Selecting the rectangle you can see it is the rectangle that is out of frame.
After trying the switch scene trick ( killed the temp scene in this image) which did not work, I closed the project and reopened it. Thing where back to normal.
The file here is before I closed the project. But when uncompressed and opened it looks normal.
You may find something. But I do not really think the issue is the projects themselves.
options.hype.zip (16.0 KB)
Thanks for reporting this. To verify the steps: if I make a rectangle in the symbol, move it, and delete it, I'm not seeing the behavior. Is this the basic steps you had done to trigger the bug?
Pretty much.
And I can not repeat it also. still not spotted anything consistent.
I don't have any logging on for hype. Is there one I can turn on ??
1 Like
I found a bug on M3, but it might be an old one.
The video shows that adding a data attribute to an item in a group and then closing out of the group in the middle of editing the data is fine. However, when doing the same thing with a symbol, it transfers the data attribute to the symbol container!
Copying and pasting the attributes would be a great feature, but this is definitely a bug.
1 Like