I like saveProjectInfo() - I suggest it be added to setup() as part of the boilerplate. I don’t see need of a UI aside from that - we’re programmers, this works. Would be nice to be able to also set an icon, but I’m sure you know that.
Icon is coming. I have big plans for the icon.
It involves saveProjectImage( “Icon”, image ), readProjectImage( “ImageName” ). These will save to .png files in the project’s directory. Any Icon.png in the project directory will be used as the project icon.
We’ll also add saveGlobalImage and readGlobalImage to save png files to the Documents directory.
I also want to expose the regular Lua file IO — but with it’s root set to the Project directory.
So - do I read right that I might also be able to saveProjectImage(“bigboom”, image) then later on do sprite(“bigboom”)? That would be way cool.
It would be nice to be able to do a read (not write) from another project’s directory, and/or to read/write global (ie. have a shared area).
Now that we have meshes, the ability to use pngs from the project directory would be fantastic. I’m experimenting with adding meshes to my shape explorer code. I have it working with colours, and now I’m trying to add images. But it’s more fun if I can use proper images rather than just stuff I can mock-up with the image class.
Oh, and I really want internal code sharing. I find that I have to concentrate on one project at a time, otherwise I get all confused as to which project contains the latest version of a particular file from my library. Being able to load files from a central library (of my own creation) would be fantastic.
Hmm.
I am getting an odd error when I have the following:
-- Use this function to perform your initial setup
function setup()
saveProjectInfo("random tests")
i = image(64, 64)
-- and more code
The error is
error: [string "-- Use this function to perform your initia..."]:3: Expected two arguments
If I add a second parameter (I used “1”) to the saveProjectInfo() call, it works, in that it doesn’t error out - but the project description isn’t set.
Yeah saveProjectInfo works like saveProjectData — it takes a key and a value. The first argument is the key. So:
saveProjectInfo( “Description”, “This will write into the description field” )
saveProjectInfo( “Author”, “This will write into the author field” )
saveProjectInfo( “Foobar”, “This will write into some random field” )
I’m getting a lot of crashes with the new build. Almost every time I try to run my cube project, it crashes. When I restart then it runs fine so my guess is that it’s to do with saving the files.
Ah - the missing info. That’s better.
It still fails with that seemingly nonsensical error if you call it with the wrong # of parameters (I accidentally left the ,1 at the end, so it had 3)
And - where is the author displayed? is it?
Hmm the error seemed okay to me: “Expected two arguments” — what was the error when you had 3 arguments?
The author isn’t displayed yet. But it’s a field we’d like to use in the future so storing author information in there now is not a bad thing to do.
Thanks for reporting this. I’ve put up a new build, 1.3.1 (5), please let me know if it fixes your crashes.
It seems to be due to the emergency-exit-gesture.
Yes, that fixed my crashes.
I like the new theme, I’d probably make it my main coding theme. Three things so far:
- The tabs are now too dim. It’s hard to read the non-active ones.
- Ditto on the suggested completions.
- Any way to dim the keyboard? It’s very bright in comparison to the rest.
(Hadn’t noticed the dedicated thread on this. Should I repost these comments there?)
It’s fine here @Andrew.
- That’s an easy fix, thanks for reporting it. I’ll make the text brighter on inactive tabs
- Also on the completions.
- Dimming the keyboard is tricky - I can certainly dim the top row, but the main keyboard is iOS standard. So I’d have to recreate it from scratch to get a dim version. Maybe after version 1.3.1, as it’s quite a big task.
The yellow “f” tabs next to functions scream “tap here to fold/unfold the function”, and they don’t, and that made me sad.
But, if they actually did that, I’d want them bigger.
Random thought: I’d love a bigger editor font. Mostly because I have bigger fingers, and I am often unable to select the correct line the first tap. I can’t be the only one. Figured I’d suggest it while you’re mucking about in the editor code.
The new theme looks really good. My only suggestion is giving comments a brighter color. I usually like comments that stand out more than code and use comments to delimit sections of code.
Maybe switching comment colors with the string colors would work better.
small bug report: lineCapMode is not drawn in light blue like all other primitive functions (it’s drawn in white). Don’t know if this is just in this theme or the original one as well
Thanks @ruilov — forgot to add that one.
Do you prefer the graphics functions highlighted? Do you think we should highlight all API calls in the same colour regardless of whether they belong to graphics?
not a big deal for me, but yes I’d highlight all the built-in API calls in the same color. A bigger deal for me is the muted comments - I like comments to stand out above anything else, but don’t know if others would agree.
Yeah I’ll bring them up. I was copying my Xcode colour scheme and copied the wrong comment colour. After you mentioned it I realised that I used the dark comment colour and not the normal one.
I might steal your color scheme at work. I’ve had the same one for a few years now, and time for a change
I spoke against instruction limit before, but now that I’m working on a largish piece of code, and using beta, it’s actually coming handy. When my app freezes at least I have a way to know if it’s my code, or if it’s codea.