GSoC Proposal the second

[Michal Suchanek]

Hello,

On 25 March 2011 23:32,  <janikjaskolski at aol.com> 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?