Not responding to taps from Mac Trackpad

[KritR]

Half the taps on a Mac trackpad are not registering. I am not doing a full click but a tap on the trackpad, which all other applications are responding to.

[mitchmindtree]

@SkeletonSlayerz

Do full clicks still work?
Is this occurring in the all_widgets.rs example or in your own code?

The all_widgets.rs example uses glutin_window as a backend - it could be possible that it is not properly registering trackpad taps? It might even be that glutin doesn't yet expose this. @bvssvni any ideas?

[KritR]

@mitchmindtree

Full Clicks do work.
Currently I have tested both examples(all_widgets.rs || counter.rs) which are both exhibiting the problem.

[KritR]

@mitchmindtree

I don't think glutin itself is the problem here. I have run the glutin examples and they seem to be responding to my clicks just fine.

[mitchmindtree]

@SkeletonSlayerz Ok, I have quite a few other issues to address first, but I will test this and have a go at fixing it soon.

[KritR]

@mitchmindtree

Sure take your time with it.

[dylanede]

I'm also getting this problem.

[mitchmindtree]

Ok, so I think this problem occurs because both the "press" and "release" events are sent within the duration of a single frame, and at the moment most widgets just check whether the mouse button is Up or Down each frame - we should probably be checking events themselves rather than just the current state of the mouse for this reason.

[mitchmindtree]

I think the easiest way to solve this for now would be to: in the case that a tap occurs and both "press" and "release" are sent at once, delay handling the "release" until the next update. This should just be a temporary fix though, as we want response to be as fast as possible.

[dylanede]

Am I correct in saying that this bug is due to a fundamental flaw in the architecture of Conrod? All interactions are based on checking and comparing states, with each widget checking the global input state and storing its own history of that state, when really an event-driven model should be used, with widgets subscribing to events (such as mouse down, mouse up, frame update, etc.). Most other GUI systems in existence use an event model, if I'm not mistaken. The current architecture, as shown by this bug, is liable to miss transient states, i.e. state changes that very quickly revert to the last state, such as a trackpad tap - this could possibly happen with devices other than Mac trackpads, such as other trackpads, or touch screen devices.

[mitchmindtree]

@dylanede yes, I think we can solve it quite easily with #569 by providing the ordered events that have occurred between updates in an ordered Vec

[mitchmindtree]

Ok, the fundamental problem should be solved by #684, which moves conrod over to an event-based user input system. Still need to move most widgets over to the new system and I've a few ideas for providing some more higher-level events, though these changes shouldn't take too long.

Thanks for raising this issue, it was definitely the first sign that conrod's old user input handling was flawed! The new system should be a big improvement :)