Code Monkey home page Code Monkey logo

leapcxx's Introduction

LeapCxx

Implementation of LeapAPI (1.0-3.0) using LeapC

Introduction

Leap SDK 4.0 deprecates the older LeapAPI, which was C++ natively. To help ease the transition, we are providing this wrapper which implements the old API (with a few minor edits) and the various SWIG-based language bindings using LeapC. Users should be aware that the primary motivation for removing the C++ API was that it had architectural constraints that made it inherently slow and difficult to maintain, so this should NOT be taken as an example of how to create a good language binding. For that, we recommend the referencing LeapCSharp binding in the UnityModules project that was designed from the ground up to take advantage of LeapC's performance.

Migration from LeapAPI

LeapCxx is nearly identical to the old LeapAPI with a few notable exceptions:

  • The configuration API is signifigantly different
  • Several fields which had been deprecated have been removed, including gestures and the interaction box
  • Static linkage is now recommended for C++

Because this is a binding layer on top of LeapC, we recommend that users link with LeapCxx statically, then ship only LeapC.dll with their application.

Requirements

  • LeapSDK 4.0.0
  • CMake 3.10+
  • C++11 compliant compiler

In addition, the Swig language bindings require * Swig 3.0.12+ * Python 3.6+ * JDK 8+

Building LeapCxx

LeapCxx builds using CMake 3.10 or higher. See the CMake documentation for more information on using CMake, and the LeapSDK Readme for information specific to using the SDK with CMake. CMake must know where to find the LeapSDK, so either set CMAKE_PREFIX_PATH to the directory containing the LeapSDK, or set LeapSDK_DIR to .../LeapSDK/lib/cmake/LeapSDK. For just LeapCxx, no additional configuration is needed.

Building SWIG bindings

To build the SWIG bindings, set the cmake variables BUILD_SHARED_LIBS and BUILD_SWIG to ON, then regenerate the solution files via CMake. The targets LeapJava and LeapPython should now be available, along with the samples for each.

Building Samples

All the samples have build steps defined as part of the cmake projects. If you'd like to build the swig samples manually, follow the steps below.

Java

cd LeapCxx/samples
javac -cp .;<LeapCxx_build_dir>/bin/<config_subdir>/LeapJava.jar Sample.java
java -Djava.library.path="<LeapCxx_build_dir>/bin/<config_subdir>" -cp .;<LeapCxx_build_dir>/bin/<config_subdir>LeapJava.jar Sample

Python

cp LeapCxx/samples/Sample.py <LeapCxx_build_dir/bin/<config_subdir>/
cd <LeapCxx_build_dir/bin/<config_subdir>
python Sample.py

Suggestions for future work

The current API, for the sake of compatibility, uses reference counting and a PIMPL idiom quite extensively. Neither of those are strictly necessary in a wrapper layer, and it should be possible to create a much faster, lighterweight C++ and even SWIG binding layer which more directly maps to the LeapC idioms and allows a more object oriented approach, for example allowing

auto connection = LeapCreateConnection(...);
connection.open();
LeapEvent event = connection.poll(...);

instead of

  LEAP_CONNECTION connection;
  LeapCreateConnection(cfg, &connection);
  LeapOpenConnection(connection);

Users wanting to implement such a wrapper should consult the LeapC documentation for more information.

leapcxx's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

leapcxx's Issues

Enable Travis continuous integration for LeapCxx

There's much room for improvement in LeapCxx, and it may soon be wide-open to the open-source community.

As small changes can break the entire build, at a minimum we should maintain a .travis.yml file to test the basic configurations we have working so far, such as LeapC++Test unit-tests and the Sample.py sanity-test.

Disentangle LeapPython/Java build from shared LeapC++.dll

Currently LeapPython and LeapJava require setting USE_SHARED_LIBS to reflect that they must be built as DLLs. However, this also forces LeapC++.dll to be a DLL, leaving a fragile binding approach that requires three native DLLs in the following structure: managed code -> LeapPython.pyd -> LeapC++.dll -> LeapC.dll

Within the above chain, LeapPython.pyd and the code from LeapC++ can be compiled into a single LeapPython.pyd. In fact with the original Leap Motion Android alpha we actually resorted to such combining in order to make things work more smoothly without too many shared object files.

This is a nice-to-have. Alternatively the community can go straight to a ctypes-based language wrapper for LeapPython and the corresponding rewrite for LeapJava, then each binding requires only a single native DLL: LeapC.dll

How to build LeapCxx inside my Cmake project

Hello,

first, thanks for providing this Wrapper for the new LeapC SDK.
I am pretty inexperienced with CMake, so sorry some newbie questions.

I already worked with LeapCxx and used for this the CMake project from this Repo. So I build my files inside the samples folder.
Well, for the future I want a clean CMake project structure, so my question is how is the best way to build LeapCxx?
I only know some basic stuff like find_package() or find_library() with the prefix path or cmake-modules. I guess it does not work here.
Would be awesome if you could give an easy example, like a minimum CMake file, to build LeapCxx.

Thanks in advance

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.