plugin to support wacom (or other pen input) on desktop (windows and mac)?

keszegh

did somebody make such a thing? now with windows export i would need this in my animation app but i never wrote a gideros plugin for windows, so i hoped that somebody will have more clue about it.

i need pressure sensitivity info from the pen, nothing else (like angle etc) is important.

keszegh

some info i've found about it that might be useful:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms699420(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/ms701683(v=vs.85).aspx

http://backworlds.com/under-pressure/

http://www.wacomeng.com/windows/index.html

SinisterSoft

+1

You should put a request on github...

keszegh

@SinisterSoft, i'm happy that you are interested in such a plugin too, i could add it as a request on github, but i wonder if it is in the scope of the main branch development.
maybe there could be a plugin tag on github and then we can have wilder requests like pressure sensitive pen support tagged as plugin request.

it is the same with having an osc plugin which would be nice and i would use it, but i'm already happy that @ar2rsawseen made some progress on it (only windows version so far), hopefully he or somebody will have more time for it later:
http://giderosmobile.com/forum/discussion/4975/how-can-i-communicate-with-other-apps-using-osc/p1

keszegh

btw with pressure info and osc control (and possibly a free general gui class) gideros could compete with things like kivy and processing in the field of programming interactive sketches. which is an interesting area for raspberry pi users too, perhaps.

tkhnoman

Hey, i actually read about this before, but haven't througly read it.
i'm an Artist, and have tablet to test. So i will try to test this

tkhnoman

I tried to test pressure, but not plugin :
http://giderosmobile.com/forum/discussion/5870/new-desktop-api-test#Item_3

@keszegh Could you check whether it works for Wacom, mine are different brand...

keszegh

it works.
this being a core feature is way better of course, i like to avoid plugins.

SinisterSoft

It would be best it the pressure was an event variable for touch rather than a replacement for id, eg: for non pressure devices it could just be set to nil or whatever the value would be for full pressure.

New devices are arriving that allow for multiple points of pressure - eg a multitouch pad with pressure for each finger - screens will have this soon too.

keszegh

"New devices are arriving that allow for multiple points of pressure - eg a multitouch pad with pressure for each finger - screens will have this soon too. " omg

yes, that's why i proposed in the other topic that it should be "event.touch.pressure" e.g. but i guess @tkhnoman wanted to do the same anyway, using "id" was just a dirty quick thing for testing purposes.

tkhnoman

Yes, adding an event mean i also must update a library. libgid if i can remember...
It would be a new event, TABLET_XXXX
It would also receive tilt.
I will try it, but not now.

keszegh

if you think a new event is better because of the logic of pressure getting, it's up to you, but in theory as an enduser it would be more logical to add it as event.touch.pressure.

but the more imporant question: when will you try it? (i'm restless)

SinisterSoft

I think that event.touch.pressure is a good idea too.

+ also maybe something to say what type of touch it is - finger or pen ?

tkhnoman

I will follow the real event model.
TOUCHES event do have "pressure" but it would be treated differently, as pressure on tablet won't appear on touch and vice versa, so it would be best to just separate them.

SinisterSoft

ok, np.

I have an intel laptop with a variable pressure touchpad, touch screen and variable pressure pen input. I should be able to test all your additions on it.

pie

awesome guys! I don't need it now, but I like it a lot!

thank you

keszegh

Some notes about supporting Wacom Pens

since some time gideros supports the pressure event, thus theoretically one can support wacom pens and their pressure sensitivity (and also s-pen etc. on android) with ease.

when i started to experiment with this, i realized that there is some error, which after a lot of discussion with @tkhnoman and @hgy29 seems to be due to new qt versions, so they could not get rid of the error.

the error is:
the pen triggers an event with event.touch.type=="penTablet" as it should, but also it triggers events with event.touch.type=="mouse", which it shouldn't.
one can work around this relatively easily, but moreover even if i care only about "penTablet" events, sometimes (but quite often) it seems like the events are received in the wrong order or something like this, as drawing a straight line sometimes makes a one-event 'turn' (i call it a 'glitch'), that is one event is one position earlier on the line than were it should be.

as even the latest gideros has this problem, i tried to make a workaround for this and what seems to work is the following:

Solution:

all 'valid' "penTablet" events are preceded by a "mouse" event, thus i handle events only in such pairs. e.g., if after a penTablet event there is another penTablet event without a mouse event inbetween, then i don't care about it.

this is only for windows+wacom, so on an android there is no such problem, and no mouse events from a pen, thus the events have to be handled normally.

this solution seems to work now (2016.06 version of gideros), although in long term i expect that in a later qt/gideros version no mouse events should appear when one draws with a wacom pen, in which case hopefully the glitch will disappear too.

btw this applies for windows, i did not have the opportunity to test on mac, yet.