Better way to manage currently active object, small API change, updated documentation, more...

[timothyschoen]

I guess I still wasn't completely done:

• The way we previously stored the current object in the Lua registry was an ugly hack. I've fixed this here. A small side-effect is that the graphics context "g" now has a state, so you need to use the ":" operator instead of "." to call its methods. I can elaborate on this more if you want, but the most important thing is that the hack is gone. The old hack could also cause actual bugs in some cases.

• Updated all documentation and examples with all the recent API changes

• Fixed all compiler warnings (for clang on macOS at least)

• Bezier paths in pd-vanilla now calculate how many lines it needs to draw to approximate the bezier curve. Before, it always used 100 segments, no matter how long the path, which is not good.

• Looking at some other signal externals, it appears the "int **w" variable I stored on the pdlua object is not needed, so I got rid of it.

• Some small improvements to the plugdata implementation

I made this draft just as a heads up that this is coming. I'll test this some more, then it should be ready to merge later today.

[agraef]

Ok, I'm waiting. :)

[timothyschoen]

Fixed some memory leaks, ran all the examples with Address Sanitizer and tested to work on Windows and macOS.

Now working on a final API change, which is how paths are constructed. I find the current API of calling path.start(x, y) to be kind of random, and we also don't want to pollute the namespace with lowercase names like that. A better replacement would be:

local p = Path(x, y)

or

local p = Path.start(x, y)

Any preference between these two?

[timothyschoen]

I've chosen the first option, because I think it more clearly communicates that this constructs and returns an object that you need to use.

[timothyschoen]

Alright this is ready! I also tested on Linux, also with valgrind, it doesn't find any problems :)

[agraef]

Looking good. This requires another Purr Data compatibility fix due to sys_hostfontsize(), but I can commit that in post. Merged, thanks!

[agraef]

@timothyschoen Just FYI, I just committed another minor fix for better Purr Data compatibility (rev. 77b2a76e3bf966b295509725aba661f6a813caf4) so that the gfx custom widget behavior doesn't interfere with Purr Data's own event handling. This only affects Purr Data.