Hello, On 25 March 2011 23:32, <[email protected]> wrote: > Hello Michal, > > first of all, thanks a lot for your feedback. > > I must admit though, that I get the feeling, that you did either not fully > comprehend my intention, > or else, have not read some of the latest research results on multi sensory > input evaluation?!
Indeed, I don't read the latest research results in every field, and multi-sensory evaluation is one of the majority I chose not to follow. Thanks for your clarification. > >> The problem with adding other clicks is that touchdown is the only way to >> move the pointer but >> also a click already. In absence of multitouch adding a right-click is >> challenging. >> Moving the pointer already causes left-click. Additional button or other >> input can technically >> produce a right-click but you would not get any coordinates associated >> with it so it's not very useful. > > I'm not sure if I understand the problem you see here. evdev incorporates a > method > EvdevProcessButtonEvent, which queries a number of filters as to if some > special event is to be > triggered. Only if those filters return false, a normal key event is > triggered. Thus I have all the information > about coordinates / click position I would need (The emulation of MB3 works > exactly how I intend to > attack the problem). The problem here is that if your filter happens to return false when the user intended to trigger it a different event is generated. For such input to be useful the filter should be some 99.9%+ accurate because the input event is triggered bazillon times under normal use. > >> Apple chose to emulate right click with long click (button down and hold >> without moving the pointer) >> or using a modifier (eg. to generate a right click you hold down another >> button and then left click) >> which are probably the only reasonable options. >> The other option is to redesign the interface to not use a right-click >> (and middle click) at all. >> This is not so difficult with touch interfaces as using controls spread >> across the screen on various toolbars is cheap. > > I own an ipad, the integrated controls feel (for me) crippling at best. If I would expect no less form Apple, they are very good at that. > the alternative to further control > elements is clustering the interface with buttons and / or hiding > functionality under random surfaces > one must either read up on or touch by accident to find out what it is, I > would rather do research on > different methods of input. The new ipad comes with an integrated microphone > :D .... The touch interfaces started out as scaled down (due to small display size) desktop systems and only begin to use some touch-specific approaches occasionally. There is large room for improvement in adapting the interface for touch based devices even without additional inputs. > >> I don't think scratching the screen is distinguishable from just moving >> the pointer. Under less than >> ideal conditions using the stylus results in various odd sounds without >> any intent, and background >> noise would likely interfere with distinguishing less prominent sound >> variations. > > I see that this may appear to be true, but if you set the properties of your > microphone properly, you > could actually scream your lungs out and the spike detector wouldn't even > bother to hiccup. > While with the same settings, you scratch the surface of the laptop, perfect > spikes are generated. > (I tested that myself a while ago) > > I even did a stress test, tapping my screen while driving close to a > construction side where jack-hammers > where used (with an open window). My algorithm could clearly detect every > tap I did. The noise did > hardly register at all. It all depends on finding the right setting for > microphone gain. This sounds interesting. Looking forward to some release of the driver. > > Again, the distinction between moving the pointer and scratching is the > additional info of sound analysis. > Otherwise, you would be right, there would be no stable way to detect a > difference. > > If you are very interested in this subject, the Natural User Interface Group > has some really awesome > approaches they currently work on. Natural User Interface Group of what? Thanks Michal > p.s. I hope, that the html errors were due to the fact that I copied parts > of my first email from an > odt file. I hope this time no errors occur. No, it's exactly the same. Perhaps you could send the email in plaintext? _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
