I will check out your experiment! (12mb is a bit big, first impression ^^)
Thanks for checking it out.
I guess the 12 MB is due to it being a complicated game engine with custom UI stuff rather than just some native OS UI and code. If I used .7z format I could get it down to about 8 MB, but I opted for .zip format for maximum compatibility.
I really wasn't intending on working on this project further, but it seems you've found a lot of bugs that need fixing!
I loaded a .txt file. Window Caption/Title is wrong, file has a name, trust me
Strange. I was pretty sure I had that working. But I see that it is indeed broken for me, too.
Fixed in the new release.
Your counters are not working? All say 0, as you can see their is text.
The counters work, but I forgot to have them update when loading a file.
If you press any key it will immediately update the counts.
Fixed in the new release.
Opening Microsoft Word files = Application Crash.
This is designed for plaintext only. But it probably shouldn't crash when an unsupported format is loaded. Upon further investigation, it looks like I made a mistake in attempting to gracefully handle errors when loading files. It was confusing because printing the error (which is an integer) to the debug log will automatically convert it to a string. But I attempted to add a more helpful message to the log and concatenate the error to the message, not realizing that string concatenation doesn't automatically cast the integers to strings.
In other words, I think the crash was caused by an error in the code meant to display useful information about an error that had been handled gracefully.
I believe I've got this fixed for the new release.
There will be a file created (prefs.dat), does not work if running inside Windows protected folders!
Good point. I was attempting to make it run "portably" and just write everything in the same directory as the executable. I didn't think about people putting it inside protected folders.
It will write to the user directory (AppData/Roaming/Deozaan/SimpleTextEditor) in the new release.
On some files the vertical scroll does not work correct, When I am at EOF the line is behind your statusbar.
Ah yes, that's interesting. It seems it doesn't always automatically scroll down to keep the caret visible. The scroll bar functionality is all built-in stuff that Godot provides. I don't know how to change it. But what I've noticed is that it has something to do with the height of the TextEdit UI control. So, for the new release I've changed the default window size which should make it automatically scroll to keep the caret visible at all times. Unless you resize the window, of course.
But since the window size is saved/loaded to prefs.dat, you may need to use the View -> Reset Window Size/Position menu item to get it to the default size again.
Program messes around with my Registry/NVidia/OpenGL settings by creating keys.
It does? So much for running it portably... I'm not sure I have any control over that. It may be something Godot does on its own. But if you can tell me what changes it makes I can look into whether or not I can prevent that from happening.
Everything is a bit too dark. Dark Menu on Dark Background... (maybe add a lightgray border to have it more seperated)
Can you be more specific about this? Yes, the backgrounds are dark, but the foreground text is light, which should result in decent contrast and easy readability.
Save As: Does not offer any text formats (Ascii, Ansi, UniCode etc.)
I think I'm going to file this one as "working as intended" since I have no plans to support anything except UTF-8 format.
I've uploaded v1.210320.0 with the aforementioned fixes to my KeyBase: https://keybase.pub/...an/SimpleTextEditor/Jotti says it's clean
.VirusTotal says it's clean