iOS and multi-touch support, use TextureFont and AppNative

[RandomEtc]

Thanks for sharing SimpleGUI. I hope these changes are useful...

We added iOS samples and fixed issues compiling the same sample apps for both iOS and desktop. We switched the samples to use AppNative and switched SimpleGUI to use the new TextureFont support that's coming to Cinder 0.8.3. You might want to leave this pull request until that happens so that people don't need to be using the github version of Cinder just to use SimpleGUI.

We also adapted the FBO sample to work on iOS. Everything should work exactly the same for desktop Cinder, but we haven't tested with Windows yet. The biggest change to SimpleGUI is to add handlers for touch events. SimpleGUI gets TouchEvents, Controls just get touches. This seems to be OK for now, but it's not as robust as the MouseEvent handling because you can't meaningfully cancel a TouchEvent that contains multiple Touches.

The main remaining issue with iOS is that everything needs to be a little bigger, which we'll look at next. Look forward to hearing your thoughts!

[vorg]

Wow. That's a big update. Haven't time to look at it before but it's exactly what I was planning to do in the next version. The main reason for postponing it was lack of clear code guidelines for cinder blocks. I was thinking about dumping mowalibs and renaming it to cinder-simpleGUI or something like that. Btw. Have you noticed any speed improvements after switching to new font rendering? My version was super slow especially on iPad v1.

[vorg]

When it comes to touch events it need a bit or rethinking to enable true multitouch interaction (e.g. sliding many sliders at once). This my require simulating mouse as single touch and not touches as a mouse clicks (as I have it now on my machine).

[RandomEtc]

Cinder's gl::drawString is unusably slow on iOS unfortunately, but TextureFont::drawString is definitely fast enough. However we've noticed it's buggy on desktop Mac OS. See http://forum.libcinder.org/topic/rfc-texurefont#23286000000912129 for details. We haven't tested Windows at all yet. I should probably have canceled this pull request until this issue is resolved, sorry.

It would definitely be nice to allow touches in multiple places. And also to stop touches from passing through the GUI onto the app below. Unfortunately it's tricky to do this in a library because touches can only be canceled by returning false for an entire TouchEvent. This is a problem because it's possible to get an event with multiple touches that don't all touch the GUI. Not sure what to do there (in my own libraries I'm dispatching touches one at a time so they can be canceled individually, but that seems like a Cinder level design decision... perhaps TouchEvent could be writeable somehow? ).

As far as blocks go I think you have it right already. Personally I would prefer one repository per block, but it's not a problem at all (see also https://github.com/BanTheRewind/BanTheRewind for another repo with multiple blocks). The instructions at http://marcinignac.com/blog/simplegui/ are great, and I followed the advice to copy the SimpleGUI folder into CINDER_PATH/blocks - that's is why I adjusted CINDER_PATH in all the samples.

[RandomEtc]

Maybe it's worth using our github at-name powers and invoking @andrewfb here to weigh in on code guidelines for Cinder blocks?

[andrewfb]

You rang :)? The events questions you bring up are good ones. I've hesitated to make the signature for the event handler virtual methods (ie virtual void App::mouseDown(MouseEvent)) anything but copy-by value to not intimidate beginners. I'm wondering if the user-supplied callbacks could have a different signature though that to allow writes, and as Tom suggested, make the event objects themselves writable. The multitouch example is the only one I've seen where this would be necessary, but perhaps there are others. The app:: stuff is still slated for a rewrite and that would be a good moment to do this.

With regards to the CinderBlock conventions, I would say a single git repo per Block is definitely ideal, and they should be designed to live in (cinder path)/blocks. This will allow users with multiple versions of Cinder on one machine to maintain multiple versions of blocks.

[vorg]

If they are designed to live inside cinder/blocks/ folder how do you develop them? Create a repo inside already cloned cinder?

/cinder
/cinder/.git
/cinder/blocks/cinder-simpleGUI
/cinder/blocks/cinder-simpleGUI/.git

That always bothers me. Or the fact that once i build cinder from source it's marked as modified and to update it from github i have to discard all the changes or commit them somewhere.

How do you solve this?

[andrewfb]

The nested .git stuff should be no problem. Git can figure out what it needs to and it seems to work fine in practice. However the modified-after-build thing is harder to solve. Best I can tell, this is a bug or at least an annoyance specific to xcode. I assume when you do a "git status" the file that is marked as modified is xcode/cinder.xcodeproj/project.pbxproj? It appears to be due to opening the XCode project with a newer version than the one that created it: http://www.cocoabuilder.com/archive/xcode/306543-xcode-keeps-altering-my-project-pbxproj-files.html

[RandomEtc]

🙈