Only touch[0] should be operational!

[eugeneloza]

Stop toying with multitouch and use only touch[0] as source of all actions (others might be supplementary). That would put much more order in Interface management and drawing, including #485

[eugeneloza]

directly link it to Cursor

[eugeneloza]

/this should finally fix all drag-related inconsistencies/

[eugeneloza]

Well, not Toucyh[0], but FingerIndex = 0 as it might be mouse right key.

[eugeneloza]

Ugh... that changes A LOT. The whole approach to touch management now seems to be in need of reworking :) Catching only FingerIndex = 0 and MouseKey = itRightButton or LongTouch on release.

[michaliskambi]

To clarify, as far as Castle Game Engine is concerned: On desktop, you always have TouchesCount = 1 or 0. (TouchesCount may be 0 before you moved or click your mouse at all.) So you have only Touch[0] (at most), always with FingexIndex = 0. Both left and right mouse button are reported with FingerIndex = 0.

In particular, note that you do not get two touches when you press two or more mouse buttons. When you press two or more mouse buttons, you just have two or more bits turned "on" in MousePressed. But TouchesCount is still 1 (because only one "finger", one mouse pointer, is moving on the screen).

You can test it with examples/mobile/drawing_toy/.

IOW, if you want to simplify things, and do not care about multi-touch:

• Ignore FingerIndex. You should not need to ever look at it. Or you can rest assured that it's always 0 on desktop.
• Ignore Touch[] and TouchesCount. Or you can rest assured that TouchesCount <= 1, and only Touch[0] is worth looking at.
• (The simplest:) Just look at MousePosition and MousePressed, only.

[eugeneloza]

Well, at the moment I was counting different mouse keys as different finger indexes (manually assigning right mouse key to fingerindex=100) and etc. I'm not actually trying to simplify code (because reworking something that works flawlessly is not a simplification), I'm trying to simplify logic of the interface drag-n-drop feature. I had an idea that the player could drag around multiple items at the same time, but that's too awkward both for the player and for the logic behind that (including which dragged item to draw and how). So, yes, at the moment I will have only 2 mouse events: Left mouse button (or fingerindex=0 for mobile) - caught onPress and tracked in onMotion Right mouse button (or longtouch for mobile) - caught onRelease This way I can "attach" much more features to the Cursor and GUI classes and therefore separate mouse management and interface interactions (which is very good for logic). Moreover now it will be clear, which touch actually does the MouseLook and DragMouseLook, and more order will be in Drag management. But, well, yes. It's almost completely rewriting mouse unit :D

[eugeneloza]

Globally, I want to reach the point where there is no difference in GUI depending input method - whether it's mouse, touch, keyboard or gamepad. E.g. Gamepad unit would only deal with gamepad-related stuff and will call specific GUI methods to control the interface.

[eugeneloza]

Ahem... funny, but I don't really understand what exactly I want here :) Keeping all touch info and copying "selected touches" to cursor or keeping only primary and secondary touch? I need to reconsider this mouse logic again, I'm obviously missing something.

Note: Keeping only Touch[0] will interfere with Android movement (if it'll ever be implemented) as MouseDrag will be preformed by Touch[0] and we need Touch[1] to handle the velocity interface element. There'll be also a problem how touches will behave if they eventually overlap the interface elements (like character space).

[eugeneloza]

Finally I see it. The Touch and Mouse behavior should be separated. While TouchDevice handles touches in one way, MouseDevice handles them differently. Maybe those should also be separated by compiler directives to optimize the amount of code compiled. Check how the detection is made in CGE.

[eugeneloza]

Stop. I don't need Mobile OS at the moment. Just rewrite it as Mouse-only solution. And later, when (if) I'll try to recover the Android support, I'll re-address this issue with help of #496