That is not a valid implementation of multitouch emulation. A double touch at position 0 and 100 is indistinguishable from a touch at 50, thus making applications like keyboard (typing and singing) and drawing unusable.

All demos you saw had 4 buttons on each corner, with the two on top being off-center or closer together than the bottom. This equates to clicking the center, or, if one button is offset, to clicking four buttons right ion the center, at the intersection of lines.

If you put anything on the screen it no longer works.

Also, you don't realize the kind of code quantity you ask for and the level of implementation. Not what seems simple to a user is simple in code. Event filtering alone needs to integrate direction vectors to determine which button pair you pressed.

Proof of concept games with fixed buttons is one thing, having a ready-for-user solution implemented in the OS is quite an undertaking.

ETA: Pycage has a point as well, more pressure on one end also breaks it.

I didn't think I'd say it, but I think you are right. So many other things need fixing first like Ovi Maps, adding more emulators and so on. Multitouch is coming in Maemo 6 which is probably the end of the year, and will have "proper" multitouch. The workarounds described here will be fine for some applications and games but not system-wide. I guess some people interested in this could try and make something useful, but it shouldn't really be anything Nokia/MaemoTeam should worry about.. fix the media player or add more plugins for conversations instead!

I wasn't talking about a particular strategy of implementation or fitness of the examples to that strategy. I was simply pointing out that there are valid use cases for multi-touch, even though some people might prefer to say that there aren't just because multi-touch is not available on their devices.

Now, if there is no way to emulate a general enough "true multi-touch" screen on a resistive screen, so that is not an option, isn't it?

What about having a "multi-touch playground", where the current ideas are tried in some kind of drawing board?

My English must be failing me because you seem to accuse some people of the sour grape syndrome.

I mean, it must be a miscommunication, you can't possibly believe that multitouch is great but we say it's not because we're jealous. Right?

I admit that the rest of the post I missed entirely. The sentence structure is "If ... so ... isn't it". I expected a then. Must be the coder in me.

As for the last paragraph, I think you want a drawing app where you can see how multitouch works. In which case, open any draw program, the one that comes with the phone is great. What you see is what you get.

The emulation has no other info than what you see drawn there. The whole talk was about interpreting some gestures (like very quick swipe) to multitouch.

back to topic please, this is about how to get "fake" multi-touch working no matter what... it will seriously drain battery, it will need lots of CPU time and so on, not to mention the coding needed in first place... there is a way, maybe many to do this, maybe its not important, that is highly up to the people implementing...



if....

Didn’t I write any in first post? Forget games! Map application and browser would be the most common use for multi-touch-likeness.

I know, there is no car holder available for N900 and even if there was you should not operate with navigation while driving. But let’s assume you do that. What would be easier? To find a button touch it accurately several times to achieve correct scale or to wipe (drag) horizontally away from centre and maybe using kinetics to zoom more than there is room in screen to wipe? I think the last one is much easier and quicker solution. And I think it would be easy to turn the map (while not moving) simply by wiping vertically at the side of the screen or circling around the centre point.

Maemo browser is a nice app but I can’t find a way how to define page width. This is sometimes frustrating, especially when using it vertically. I have seen lot of pages trying fit into this narrow width and they look really silly. So one use-case would be to zoom out and the page will resize itself into new screen scaled with. Next step would be to zoom in back. Maybe I am a bit naïve but I imagine it as two simple wipe actions.

"games and zoom" well rotation then...

do we now continue with "what and how and why" or is this going to be a brainstorm? we already know what is wanted and what cases it might fill...
but if there is no algorithm and no code there will be no implementation, does anybody know an implementation of fake multi-touch? not the one with fixed points multi-touch-like behavior stuff

another idea would be to get a resistive "multi touch enabled" screen upgrade to the n900 and just close this... (yes there is... not for n900 but there is...)

Have you seen this?

http://forums.internettablettalk.com...147#post469147

Ok. This was definitely a huge eye-caching post. I just had to respond it.

Some comments:
a) Yes, is it bad? I use it most of the time by holding it with both hand.
b) I do not agree with you, I hope I am not the only one.
c) I don’t understand where is the large image a case?
d) It is confusing. Why are you talking about images? I would zoom surrounding with image not only image itself.
e) What is about stylus? You can use it if you like. Drag a fixed point from left side of screen (like hover mode) and do your zooming around it. Or hold a button on top of device and use the fixed point in center of screen.
f) I agree but using zoom for on-screen keyboard is not a good use-case.

I sense some criticism against me. I read it three times just to be sure it really didn’t say anything beside emotional opinions. Do I have to explain myself?

I posted this brainstorm just to get some ideas off from my head, hoping that maybe somebody will pick some of them up for good use. Because someone has 5000 other ideas does not mean that I did something wrong? Or does it?

So, let's talk about ideas regarding this brainstorm not others. And feel free do add some.
Henry

There's a reason pages don't fit into the browser: the page has been written with at-least-this-high controls for usability and alignment. Break the rules at your own peril. As for zooming, swirl and volume buttons. In portrait, they are under your finger.

As for "I'm driving and pinching is easy", so is swirl. And the (hw) zoom buttons. And double tapping. And I know I'm going to get stares for saying this, but it's a laptop with a GPS, not a PNA. It will never be. Put it near any of my navigation devices and several points will strike you as neigh-unusable. I won't get into them here. And a PNA is about 1/6th price.

It's a good idea in principle, but its uses are quite limited.

Chemist:
You are technically right, we are off-topic somewhat, but I'm trying to make a point: Make sure you (all) know what you vote for. This isn't multitouch, except emulated. This is a poor substitute for a limited function feature that is a side effect of another touch technology (like pens are to resistive).

I would hate for this to get started, or even finished and then to hear "Awwww, I can't zoom images like on iPhone! Maps is shaking when I hold my finger down! I can't click 2 buttons at the same time! You said this is multitouch!", actually wasting man-hours of some critical people who write this thinking we know what we want.

--

Anyway, I have very little else to say in this matter, most of what I wanted to get through is already posted. I just hope people actually skim through the thread first.

As for HOW, was this ever up for debate? Emulating MT on a resistive screen is based on the fact that muti-touching a resistive screen starts at the first point, then as you touch the second, the actual detected point is the vector average of the said touch points.

The whole shebang works on the principle that if you move from point A to B in one single poll cycle, you might have just used a second finger.

Ex:

xxXxxxxxxxxxxxxxx T0
xxXxxxxxxxxxxxxxx T1
xxxXxxxxxxxxxxxxx T2
xxxxXxxxxxxxxxxxx T3
xxxxxXxxxxxxxxxxx T4
xxxxxXxxxxxxxxxxx T5

This is a swipe. You can see the user touches, moves, then stops. If the T5 is missing, it's a kinetic swipe (user wiped and released, T5 is all small x).

However:
xxXxxxxxxxxxxxxxx T0
xxXxxxxxxxxxxxxxx T1
xxxxxxxxxxXxxxxxx T2
xxxxxxxxxxxXxxxxx T3
xxxxxxxxxxxxXxxxx T4
xxXxxxxxxxxxxxxxx T5

Above is a multitouch. You see, as the screen registers the second finger, the touch point jumps in one screen poll. First finger is at grid 2, the second is at grid (say) 12. This results in the point jumping from 2 to grid 6 very fast. Once that happens, the touch point is considered multi-zoom or multi-rotate around the initial touch.

There are several issues with this, among others that
* Normal filtering of events, as is, has to be rewritten. Because:
* Right now very fast swipes are likely errors and filtered or averages out.
* Large contact patches are also ignored: you can swipe the screen with your hand if you do it right and maintain a very large area.
* As soon as the cursor moves over 5 pixels or whatnot, it dismisses the "touch" event and moves into hover/drag. You can no longer push buttons until you release - otherwise lists are unscrollable.
* All kinetic scrolling needs to be rewritten, as second touch sends them flying (that's they are filtered). The GUI is also filtered in many instances because you should not be able to scroll through desktops at fifty/second. Any control that is not multitouch-prepared will flail wildly.

Note that as the cursor moves to the intersection, it's then stopped so it's not like it scrolls forever, just very fast.

Also, error/noise filtering will be shot. Tests this: Put both your fingers on the screen. Now vary the intensity of the push, but don;t take your fingers off. It should maintain touch, just vary the touch point. It clicks.

As a final observation, this is very hard to do system-wide. An application could work, though, recognizing the sudden movement and interpreting them as gestures for rotating, zooming. There is nothing keeping an application from doing this now.

Fire up sketch and draw a zoom gesture. It looks a bit like a slice of pie. That gesture could be implemented as zooming.

ETA: Some of you posted while I was writing it, and my reply overlaps with some of your posts so it might make a little less sense now.