Wow, that's smart! I've still got 3.01 on my nSpire CX and 3.02 on my desktop software. Is there an easy way to get the print output (either on the desktop or calculator)? Could you maybe add the custom print() function to the inspired-lua wiki?

But how does that work? Do you output the _G variable?

Sorry, maybe I wasn't clear enough. I understand that works, but why does it work? Why can't I just set the screen using platform.window.screen? That's more logical...

Yes, that's true. But I somehow can't add new properties. For example I'm trying to do this:

-- Doesn't work: attempt to index local 'self' (a user data value)
platform.window.screen = main

-- Doesn't work, I can call the function but the function throws the same error.
function window:setScreen(screen)
    self.screen = screen
end
platform.window:setScreen(main)
But both methods don't work. The only thing that does work is modifying to metatable directly, so by doing window.screen = main, but I don't really like doing that (except for the default value).

Am I doing something wrong?

Yeah, you're right. People don't have to take everything, they can just take the functions they need. I'll just continue writing my library from the ground up for now, and I'll post it when it's largely finished.

Mmm, I'm not really sure about that. On one side I think it's a great idea: it's always better to have more people working on something and your BetterLuaAPI has a couple of great functions. On the other hand your library takes a different approach than the one I'm working on: I'm trying to keep all drawing code in the graphic context object, all logic (like clicks) in a to-be-created screen object and I've got a couple of other different ideas... Furthermore I'm a bit like a minimalist programmer, for example (to be blunt): I don't see the point in your color table or a square function...

Not to mention that I've got just 50 lines of code... What do you think?

Shouldn't that be possible? Isn't it just stored in a property of the object? Your workaround is also a good solution, but not as clean as I'd like. :p

What do you mean, the color can be changed when drawing an image?

Quote from: Frog on September 02, 2011, 12:56:55 pm

Quote from: adriweb on September 02, 2011, 12:26:06 pm

Good ideas in this topic !

However, I should point out that using platform.gc() is discouraged, and is generally a bad idea.
(multiple reasons like the fact that it's not working the exact same way as the 'normal' gc, and for future compatibility matters...   )

Somehow I overlooked your post... Anyways, isn't it true that the usage of platform.gc() in jimbauwens' example is no bad practice, since getmetatables is just a reference to the original metatable shared by all gc objects? I mean, you do use the passed gc in the on.paint() function, so that shouldn't give unexpected results?

Don't you agree that this way looks like a better method for a GUI library?

platform.gc() is a constructor of a new independant gc object.

What does the TINspire framework is :

Code: [Select]

local gc=platform.gc()
gc:begin()
on.paint(gc)
gc:finish()

What does that mean ? On each screen refresh, it recreate an independant gc object that has a different reference.

And since it is a different object, using methods such as setFont/setColor won't change gc, but your new object you define each time you use platform.gc.

If you want to store this gc in on.paint(), it won't be drawn as it, since it has a different reference/address

In Jim method, you define, yes, one time a new object, but you pick up its meta table. It is not the same. Each gc object has the same metatable, but not the same properties.

Yes, I understand. The metatable is basically the blueprint and obviously every instance has different properties. I'm using to Jim's method to create a simple graphics library now. Should I release the code when I'm finished?