On Wed, 2 Oct 2013 22:28:54 -0700 Jason Gerecke <killert...@gmail.com> said:
> On Wed, Oct 2, 2013 at 8:21 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
> > On Wed, 2 Oct 2013 13:59:47 -0700 Jason Gerecke <killert...@gmail.com> said:
> >
> > 3 things here.
> >
> > 1. for general device queries (get name, description, device classes etc.)
> > there is already an evas_device api. right now though nothng populates the
> > evas device information from lower levels (xi/xi2, etc. etc.), so it's
> > unused. but it's there.
> Would clients be expected to call this just once prior to receiving
> input, or is there some way to notify them that a change has occured?
the query of the devices and building of their nodes and tree should be in
ecore-evas. EVAS_CALLBACK_DEVICE_CHANGED is already there for this - u can set
a callback on the evas itself to listen for this. the idea is that if you get
this callback - re-query the device tree and see. :)
> I ask because the type information (e.g. pen tip vs. eraser or
> airbrush vs. inking pen) is likely to change fairly regularly. We
> would want to be sure that clients can get their hands on that,
> whether it means notifying that they need to refresh their
> understanding or sending the type information in each event.
well the device add/del is really more about plug and unplug. here i'd expect
there to be a single device representing the pen and pen vs eraser vs brush i'd
expect as a mode field on the pen (like i mention below about eraser)
> > 2. i've talked with some people about this and the general take was that we
> > need to add new pen events (ala multi) because they need to handle more than
> > multi: e.g.:
> >
> > * button number on pen pressed/released SEPARATELY from pen touching.
> > * pen touch vs eraser touch (ie indicate which "end" of N ends a pen
> > presses down).
> > * some pens support a hover ability - so that means motion events without
> > down/up begin/end points like multi, BUT we would ned/want to report
> > distance as a value during this hover
> > * possibly other custom inputs on the pens themselves that are not
> > accounted for.
> >
> > we COULD extend multi events and add fields, but i think you are mistaking
> > habitual over-engineering in efl for intent for these to be pen events. a
> > lot of stuff gets extended beyond its initial scope "in case". eg in case
> > out touch surface can report size, pressure and angle of your finger... :)
> > also it'd cause issues with existing multi event usage.
> >
> As I said, the multi event is interesting for its extra fields, but
> might not be a good semantic match. A pen isn't anything more than
> fancy mouse: it has motion without a touch event and a set of buttons
> to worry about. The only thing that makes it special are all those
> extra axes, and most of those could be imagined on a
> sufficiently-advanced mouse. Wacom actually makes such a "mouse" for
> their Intuos tablets which reports things like height above the pad,
> rotation about the z-axis, and absolute position of a spring-loaded
> fingerwheel.
>
> The way most APIs handle pen input is to just pass the data alongside
> the X/Y position you'd expect for a mouse. Throw in an enum or
> function to let clients distinguish pen tip from eraser and you're
> set.
i'm thinking similarly - have down/up and move events, with a bunch of extra
fields. only q is.. what set of fileds pretty much covers every aspect of a
possible pen.... :)
> > 3. if you want to tal about the extra buttons and what not that you find on
> > pen tablets (i have a bamboo sitting on my desk at home - i know cheapo
> > little pen tablet, but its indicative at a small scale of a lot of them), i
> > believe these should just be "keys" like any keyboard. i don't think these
> > belong in any specialized event system. as with #1 we CAN attach a special
> > device handle to them though so you can differentiate where the key comes
> > from... :)
> >
> Most implementations send these as "buttons" rather than "keys". In
> the case of evdev, the Intuos and Cintiq tablets will send the
> "meaningless" BTN_{0,1,2,3,...} buttons. For a Bamboo though, you'll
> find the mouse buttons BTN_{LEFT,RIGHT,FORWARD,BACK} instead. In the X
> driver these are all mapped to mouse buttons that clients can easily
> understand. The first few mouse buttons usually have attached
> semantics (e.g. button 1 => left click => primary action) which makes
> them non-ideal, but "keys" don't fare much better since you'd need
> clients to properly understand a non-standard keyboard layout. These
> buttons are always a tricky issue.
sure, but i see keys as better as they have keysyms at least that have
enumerations... if the intent is to emulate a mouse - then buttons sounds
right... anyway... if buttons then its kind of weirs to expose a button pres
from the tablet base as this press event carries x/y info but actually has
nothing to do with location... :)
> > adding new event type isn't too hard in evas - you add the structures,
> > enums (at the end of the current list of callbacks), add the feed api's to
> > feed the event in, add the appropriate routing (the same we do for multi
> > and mouse), and then that's done.
> >
> > then there is edje - likely you want to expose the pen events as signals
> > like mouse. maybe not? optional really.
> >
> > and the important bit then ecore-evas + ecore-input + ecore-input-evas
> > needs to gather the events from the next layer down and call the feed
> > calls. the layer below could be evdev/console input devices (fb) x11
> > (xi/xi2 etc.), or wl.. or win32.. or anything... and then for these
> > ecore-x, ecore-fb, ecore-wl etc. needs to gather the appropriate events
> > from the display system/event input system below that. one thing missign in
> > ecore-evas is what i describe in #1 - querying all available devices,
> > monitoring for new devices being plugged/unplugged and appropriately
> > populating/managing the evas_device tree per canvas. :) it's something we
> > need to get around to ding some time... :)
> >
> Sounds like there'll be a bit of code spelunking in my future. I'll be
> happy once I wrap my head around how each of these components (edje,
> ecore, evas, etc.) fit together.
indeed. i hope this helped a bit. keep this dialog going and ask questions,
swap initial struct definitions or ideas etc. :)
> Jason
> ---
> Now instead of four in the eights place /
> you’ve got three, ‘Cause you added one /
> (That is to say, eight) to the two, /
> But you can’t take seven from three, /
> So you look at the sixty-fours....
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
