Hi I'm just wondering if it's possible to do it? Such that I can type with one hand holding a stylus and another just fingers. Currently it prevents touch input when the stylus is hovering or touching the screen
Related
Something along these lines may have already been created, but I havent been able to find it. Shell software, and touch flo is all very good for using our phones without a stylus, but we all know that at some point we are going to have to use a piece of wm software, and out the stylus comes.
What I am proposing is a virtual mouse cursor. I came across Innovisoft Virtuamouse, which is controled by the d-pad, but why not have a cursor about 50*50 pixels, which can be moved by finger.
In my paint mockup picture, the red circle would be where you touch to drag the cursor, and the tip is the active point where the stylus would tap. It would be moved by dragging, and a stylus tap would be signified by removing and replacing the finger within 200ms, like a laptop touchpad.
This cursor would probably be turned on and off by a hardware button.
Unfortunately I am not a developer, so this would have to be a project for someone else, but I'm sure people would be willing to contribute.
Since the Diamond having multi-touch seems to be comfirmed (link below), I would bet that one of the first things we see from deevelopers is just this idea. Using the touch-sensitive part of the area around the action button as a trackpad and clicking with a button press.
Diamond multi-touch vid: http://www.youtube.com/watch?v=f3Owgcos_KY&feature=related
Seems like a good idea, but I do have to question this a bit. You want to use a touch controlled mouse to tap a button? It seems like a bit more work to do. Also, your picture is a smartphone....
The idea is to use the mouse to press the odd, fiddely button, not for constant use.
As for that being a smartphone screen, that was an overlook on my part - I just grabbed the first screen capture off google images.
I think it would be useful for web browsing.
Surur
Hello XDA-ers.
I have a Moto Atrix MB860 and I can never really find a comfortable way to hold the phone which allows me to single-handedly thumb navigate and type like I could on my old HTC Vogue. I think the issue (and it's the same for most of the candy-bar smartphones) is that the menu buttons and keyboard live at the bottom of the screen, which occupies most of the phone's length. When I grip the phone high enough so that it's not at risk of falling out of my hand, my thumb can't comfortably reach down to the bottom of the screen. If I turn the phone upside down - so the business end is near my fingers instead of the heel of my hand - I can reach the menu buttons AND the soft keyboard quite easily. The only problems with this are that everything is upside-down on the screen and the hard buttons, etc. are in the wrong place. Does anyone know of an alternate keyboard, or a way to configure an existing keyboard so that it lives at the top of the screen instead of the bottom? I can't imagine that there isn't a single implementation either by a third-party or by a handset manufacturer.
Thanks.
I noticed in many programs that when you interact with the touchscreen it gets locked out of getting touched in other places. For example......... in the unblock parked car game you move a car by touching and sliding it... and while you are slidig it any input anywhere else on the screen is blocked out. Is that because instead of programming the touch from scratch the app author is using some premade gesture? Is it possible to have the touchscreen open to input even while it's being touched somewhere?
case example: suppose I have a drawing application. I want a virtual button in the corner and when I press and hold that button down touching the screen goes into erase mode instead of draw mode. Would that be possible? Would holding down the virtual button block the input on the rest of the screen so you couldn't erase? Or is this possible?
It is possible as long as you know how to code it.
Sent from my toaster.
Hello, I am trying to get familiar with this device and those S-pen enabled apps. How does palm rejection really work? It seems that if the pen touches the screen first and then I rest my palm on the screen, there is no marks made by my palm. If I put my palm on it first, depending on the settings, sometimes my palm leaves some marks.
While using the handwriting feature, I often hit the large space bar by mistake. Any way to avoid this while resting the writing hand on the screen?
There's subtle nuances in terms of performance of rejection of stray touches depending on the application that you're in. Some apps handle it better than others.
For example, in Action Memo as you lay hour hand down to start writing with the stylus it may leave a stray mark. Experiment with this by having the first touch of your hand be your knuckle of your pinky. Drag your knuckle across a little before bringing the tip of the pen to the screen. That stray mark stays there when you're done with your writing with the stylus.
Now repeat the same test in S-Note with finger input enabled. Again practice the motion of keeping your knuckle on the screen and dragging, then bringing the pen to the screen. Notice anything different? As long as you haven't lifted your knuckle, S-Note deletes the stray line the moment the pen gets close. Any marks you've made prior to the pen getting close to the screen stay there however.
The point being that the answer isn't as straighforward as you might think. Here we have two examples of two applications made by the same developer (at least you would THINK its the same developer) yet they act completely different. When writing with these devices one has to be deliberate in when and how they bring their hand and pen to the screen. With practice this becomes second nature though. It definitely helps when note taking apps have the ability to ignore finger input.
With regards to your problem with the handwriting recognition pad used for text input . . I'm with you there. The location of that space bar and all the other buttons is mindbogglingly stupid. They should be located above your palm. IMO what we have here is a classic example of the porting of a function that was developed for phones held in your hand (whereby you do not need to rest your hand on the phone) to a tablet without realizing that the usage of the function would be different on the new hardware.
Hi... using styli on tablets is new for me, and some general guidance would be appreciated.... I'm looking for palm rejection solutions for Samsung Tab devices that (unlike touchscreentune) don't require rooting.
We have some of these Notier styli in-house, and certainly they provide a very nice writing experience, except of course that S Note doesn't have palm rejection so the stylus can't be used for note taking.
A Microsoft Surface 3 will arrive later today, and it has a resistive screen, Wacom stylus and palm rejection, so that should work well. But we'd like to use cheaper Tab devices as well.
Our applications are general note taking (instead of legal pads) and also annotating medical images.
Just my opinion here but the perception that palm rejection is not present is not a black and white thing. Rejection of stray input has more to do with touch sensor type of the device, the application used and the way the device is used within the application in question as opposed to a device itself not having palm rejection support.
Take a capacitive sensor based screen for example, where the user holding a capacitive stylus in hand and he/she brings the hand down to rest on the surface to begin writing. For a brief moment some other part or parts of the hand/wrist are going to contact the screen prior to the tip of the capacitive stylus. Without any other means of knowing how to interpret these inputs the software is going to have to consider registering them somehow. As long as these points of contact don't move significantly before movement of the stylus tip begins the application that is active can then make sense of what is going on and begin to reject the touch inputs from everything but the stylus tip. This is how "palm rejection" works. All touch input has to be evaluated and then the application decides what is input and what isnt.
IMO devices with active stylus support are always going to have an advantage when it comes to "palm rejection" in that software applications can be written in such a way as to completely ignore capacitive touch when the pen is in range of the screen. LectureNotes app for example can be set to completely ignore finger touches for writing operations and I'm sure this is not the only application that can do this. That isn't to say that this is a global feature that ALL apps inherently have, but rather it is a feature available to developers based upon how they implement things. Devices limited to capacitive stylus support only will always be at a disadvantage because the device will not perceive a difference between the tip of a stylus and a finger.
Aloha...
Yes, that's right... the application needs to work with the touch screen driver to reject inputs that aren't useful.
With the Samsung Tab Pro 12.2, resting one's palm on the screen completely disables the ability to write with a stylus (using S-Note), so it's pretty much hopeless, at least using S-Note. S-Note is nicely integrated with Evernote...
Will give LectureNotes a try. It mentions being "usable" with Samsung Tab products, so let's see if it can reject palm pressure.
Palm Rejection just means you don't smudge your drawing/writing with your palm whilst resting it on the screen.
Remember how you used to get a black palm from the ink as a kid, and your whole paper was covered in smudges? That.
It is not a 'Disable Touch Input' feature. It does not disable touch, it does not disable the buttons, and it does not restrict input to the Pen only.
If you're rooted, this is an option: https://play.google.com/store/apps/details?id=com.gmd.spencontrol
My device isn't responding normally Especially keyboard when i write leftside and the same side when I rotate it and touch also not the same and sometimes it pressing itself :crying: