OSX Support

[croepha]

No description provided.

[ApoorvaJ]

Thanks! I have a backlog of pull requests for this repo. High time I got to them. Will have a look this week and get back to you. :)

[serge-rgb]

Hi!

I tested the PR. It works, but I have a couple of arguments against it.

These are some of the costs that EasyTab incurring on top of the OSX API

• An extra dependency in the user code.
• EasyTab_HandleEvent needs to be called from the right call sites
• EasyTab_Load() must have been called, calloc could fail
• need to call EasyTab_Unload() if we care about leaks.

And the win we get is that instead of doing this:

   loc = [theEvent locationInWindow];
   mMouseX  = loc.x;
   mMouseY  = loc.y;

   if(mEventType != NSMouseMoved)
   {
      mPressure = [theEvent pressure];
   }
   else
   {
      mPressure = 0.0;
   }

the user can do this:

    EasyTab_HandleEvent(theEvent);

    mMouseX = EasyTab->PosX;
    mMouseY = EasyTab->PosY;

    mPressure = EasyTab->Pressure;

A little bit less code, but it seems to me like EasyTab on OSX is a net loss for the user.

The big thing for me is that the API might have to change.

Getting a single wacom packet per frame on Windows caused a problem. It turns out that Wacom says that the "right thing" to do on Windows is to get as many packets as possible from the queue each frame. This means that in the future it might be better to have something like EasyTab->Pressures[...], or else some applications might overflow the wacom packet queue. If we end up making that change, backporting it to OSX would make the API awkward compared to OSX.

So far I am seeing mostly downsides. EasyTab makes wintab easy, but it seems like it makes a super easy OSX API way more complex.

Sorry if I'm coming off as too critical/negative! But I'm trying to think of the costs of maintaining this in the future.

[croepha]

I think I agree with @serge-rgb almost completely. I was mainly thinking that this was a good move for porting and just for the sake of completeness. But I don't think that should be gained at the expense of long term maintenance

[GrayHatter]

uTox is a Tox Messener client that runs natively on osx, windows, and Linux. It does not yet have tablet pen support, but it's something I plan to add. If you do merge this, I dont have to write the api 3 times, just once.

After having to implement drawing, mouse, keyboard, x... I was stoked to find this... I could make the same argument for both windows and Linux.

Before EasyTab you had to know 3 APIs, after, just 2. With this, just one.

Just because it's easier in OSX isn't a reason to not support it.

[croepha]

I'll leave it to the maintainers to decide how to move forward, if at all... I personally won't be offended if it gets closed. @GrayHatter in the meantime, you can use the version from my repo: https://github.com/croepha/EasyTab

[serge-rgb]

The same argument can not be made for Windows and Linux. Easytab solves a big problem on both of those platforms - it provides a simple and easy to use API for Wacom tablets. OSX is the only platform where EasyTab seems to introduce more problems than it solves, but I would love to be proved wrong about this!

If you do merge this, I dont have to write the api 3 times, just once.

Even when using EasyTab, you would have to write the code three times. The function signatures are different for each platform. If you're going to have three call sites, you might as well use the API that is simpler and less error prone. In OSX the tablet API is the mouse API. If you need pressure info you do [event pressure].

I'm willing to maintain a OSX version of EasyTab if it solves a problem. What problem is this solving?

[ApoorvaJ]

I think that we should defer this judgement call for a little bit. I will get around to finally looking at the Wacom button APIs and other pull requests on EasyTab this week.

All things considered, I don't think EasyTab is an inherently high-maintenance library. Once the feature set is in, it won't change very much over time. Because of this, I think there is value in adding Mac support, just so that EasyTab can become a one-stop solution for all tablet input needs.

A good balance between @serge-rgb and @GrayHatter would be to not add Mac support for a little bit, until we stabilize the Win+Linux APIs, and then figure out how/if to integrate Mac. We don't have a lot of users at the moment, so I'm okay with changing the API if it helps the library in the long run and across platforms.

In conclusion, I'm keeping this PR open for the moment. Hoping to make some progress on button APIs, screen mapping and input queuing this week. I will be talking to @serge-rgb to discuss things along the way.

[Apostolique]

Can I revive this pull request? I'm looking at a cross-platform way to add tablet support in a MonoGame game (Windows, Mac, Linux).