[MartinH]

I just got a Galaxy Tab S8+ with an S-Pen, and I'm seeing some odd behaviours while annotating. 

The main thing I noticed is that the pen button seems toggle things when you press and release the button, but it should only switch the tool while the button is held down. To be more specific:

Undo:
If I set the button to the Undo function, it only works every second time I press it.

Toggle:
Pressing and releasing the button toggles between the current tool and erase. Or if I hold it down, it stays on erase until I erase once, then switches back. What (I think) should happen is that it keeps erasing until you release the button, then switches back to current tool. At least that's what my Surface does. Here's a video of the behaviour. Note that you can hear the clicking of the button to tell what I'm doing.

Toggling the wrong tool:
If I switch the button to use a different tool, pressing and releasing the button will toggle between the one in the setting and the previous one in the setting, ignoring the one that was actually selected in the annotate window. You can see this in this video. 

Holding the button:
When you keep holding the button and write something, every time you lift off the pen, the tool toggles between the two tools. See this video.

Leaving Annotate mode:
If I leave annotate mode and try writing again before moving the pen away, the first touch does nothing. See this video.

This can be hard to explain, so if the videos aren't clear, let me know.

[Zubersoft]

I added support for S-Pen air action but presses with the last update, so what that means is that, if you have "Air actions" enabled in the tablet settings under Advanced fetuares->S Pen, then MobileSheets will respond to button presses even when the stylus is not touching the screen. This overrides the behavior where you have to press the button and touch the screen to temporarily switch tools. This is, in my opinion, the expected behavior when air actions are enabled and is nicer because you can change tools with a button press, annotate, then press the button again to switch back to the previous tool. It's just less awkward than having to hold the button while moving the stylus. If you don't like this behavior, then disable "Air actions" in the tablet settings, and you'll get back the old behavior.

I'll take a look at the videos you provided and address any issues that need to be fixed. I really would prefer not to make the button behavior configurable as you can just turn off air actions in the settings, but if you feel strongly about having a setting in MobileSheets, we can discuss it.

Thanks,
Mike

[Zubersoft]

With the last issue you reported, this is apparently a framework issue that I can't easily get past. Basically what seems to happen is, if you have the pen hovering, then you close the annotation editor with the pen, still maintain the hover, then press down, the touch event is delivered so I can switch into the annotation editor, but then no touch events are generated at all. The OS is basically no longer informing me of any of the touch events until the pen is lifted and pressed back down. If I had to guess at what is going on, it seems to have to do with the fact that, when you hover, MobileSheets instantly switches to the annotation mode and when the pen is pressed down, the view that is getting the touch event is the invisible layer that you write on in the annotation editor. However, when you leave the annotation mode, then press the pen down, the view that is getting the touch event is the parent view that controls laying out all of the pages. MobileSheets switches to the the annotation editor in response to the stylus touching the screen, which places the invisible drawing layer on top of everything, and this causes the OS to cancel all future touch events because it recognizes that the user is now pressing on a different view than the one that started all of the touch events. So there is no easy solution for me with this because I can't force the OS to switch targets for the touch events without the user first lifting the stylus and pressing it back down.

Mike

[mdavej]

My S pen doesn't behave like the OP's. Pressing the button while hovering toggles Air tools as expected. Pressing while writing erases as expected. I don't see anything abnormal or undesirable about this behavior. I'd prefer no changes at all.

[Zubersoft]

There were a few bugs and I have fixed them. If you toggle between two tools, it would work fine, but if you then selected a different tool with your finger, the toggling behavior would not work properly. There was also an issue as Martin described where it would switch between tools if you held the button and then lifted the pen, which is not how it should work with the air actions enabled. It should just toggle when you press it and then toggle back if you press again. It should not be used/held while writing unless you want to disable air actions.

Mike

[MartinH]

Ok, thanks for the explanations. I can try out disabling air actions and see how it works. Is there a new build you would like me to test with the fixes you mentioned?

[Zubersoft]

I've sent you an email with a link to a build with the latest changes Martin.

Thanks,
Mike

[MartinH]

I tried the new version and the toggle bugs seem to be fixed. 

When I disable air actions, things work as I expected when holding down the button.

What are the air actions supposed to do in MS? When I try performing the gestures (hold the button and make a V motion), it does the global actions (home button or back button or whatever), nothing specific to MS. So I'm not sure why disabling them changes the button toggle behaviour.

[Zubersoft]

The "Air Actions" setting is required for the button trigger to be recognized with the stylus not touching the screen. I tried to add support for the air gestures, but Samsung's library is awful for that, and I would have had to implement my own gesture detector without conflicting with the existing touch interactions. It just didn't seem worth it. So MobileSheets will not respond to the air gestures.

Mike

[MartinH]

Ok, I think I understand how enabling Air Actions is needed for you to get the button triggers. I would say from a user perspective, it's not very intuitive to say to turn on or off Air Actions to switch between toggle or held button behaviour, so a setting would be more obvious. But I also understand that you don't want to add settings that few people use. For me personally, I can get the behaviour I want so I have a strong opinion either way.

I've seen your posts about the difficulties in using Air Actions, but after looking at the settings I wonder if there's another way other than interpret your own pen movement. In the settings here, there are a few non-Samsung apps (Gallery and Office) that appear in the list of apps that support gestures. It seems as if there's a way to register that your app supports certain gestures so that they appear here, and maybe you receive an intent in your app.

Also, I found a couple of other (maybe) bugs:
Even knowing that if I tap the screen to get into annotate mode without lifting the pen the first tap is ignored, there are times when the first tap doesn't seem to respond - even when I never left annotate mode. I've tried reproducing it intentionally and haven't succeeded, but it happened several times during a rehearsal when I didn't have time to test it out. So I don't have a reproduction procedure, but I'll keep watching out for it.

Also, I've been trying to use the 'write in a text field' function with the pen (tap any text field with the pen and whatever you write will be converted to text with handwriting recognition), and it is a bit odd with the text annotation tool. If I tap to place a text field, the cursor changes to the write cursor which allows me to write, but unless I'm really close to the flashing cursor, it drags a box instead of writing. It's a bit clearer what I mean from this video.

[Zubersoft]

When I wrote this "I tried to add support for the air gestures, but Samsung's library is awful for that, and I would have had to implement my own gesture detector without conflicting with the existing touch interactions", it was in reference to trying to register my app to receive S-Pen gestures. Samsung describes that here: https://developer.samsung.com/galaxy-spe...tions.html

There were multiple issues with this:

1) I implemented everything exactly as they described, but could never receive any gestures from the OS
2) The "enable_key" section says that the Air Actions won't be enabled by default unless users explicitly know to go into the settings to enable them for MobileSheets. This would defeat the point as most users won't even know to do that, even if I fully document it, as most users won't read the documentation. I would have to get Samsung to do an extensive review to determine if they would allow it to be enabled by default for my app, and even if they did allow it, it wouldn't take effect until an OS update is rolled out to users. 

So given that I could never get it to work, the only option open to me is to receive raw movements as described here: https://developer.samsung.com/galaxy-spe...e-sdk.html. However, that doesn't handle gestures - I would have to write my own gesture detector to figure out what the user is doing with the S-Pen, and I don't want to take on that work anytime soon. There just isn't enough value in it. If someone else wants to write a gesture detector, I'll happily test it and consider adding support for it.

It's possible I made a mistake when trying to register my app with Air Actions, but there are too many other higher priority things to work on for me to spend any more time on it at the moment, especially given #2 above. If some other developer wants to test out their Air Actions SDK and can get it working, I'm happy to work with them to get it integrated in MobileSheets.

If the reason you saw the bug with the pen is due to what I described previously, that's not going to be something I can fix. If it's due to another reason, then I'll certainly look into it, but I'll need to know how to reproduce the issue. 

As far as the writing issue, that's most likely because the text component you are interacting with is very small - about one character wide. I don't increase the width of the text component larger than it needs to be. However, if you draw a box for the text to start with and make it much wider, in theory that could make the edit component wider as well, but I'd have to run some tests to verify that. I can consider making the default text component wider than the underlying annotation (ensuring it has a certain minimum width for new text annotations). I could also detect when a stylus was used to create the new annotation, and only increase the width in that scenario. To be clear about what is happening, when you are editing a text annotation, I hide the annotation and replace it with a editable text component that has a transparent background. This allows the text entry to work as normal and still provides the expected behavior (like being able to select text, copy/paste text, etc). With a new annotation, the editable text component is only one character width or so because no text has been entered yet.

Mike

[MartinH]

Thanks for the clarification about the problems with air actions. It's not a feature I'd probably use, so I wouldn't ask to have support added.

As for the writing in text fields, I think the main thing I would expect is that if the writing cursor is shown (the blue squiggle), then the pen input is treated as writing. Currently I don't know what will happen because the cursor does not correctly indicate where I can write. Is it possible to make sure the area that triggers the cursor to change matches the area that is writeable? I guess the area could be larger too, but it's the mismatch that I find confusing.

[MartinH]

I think I'm able to reproduce the bug where the first touch does not work sometimes. It seems that if I stay in annotate mode and don't touch the screen for more than about 30 seconds, the next pen touch does not work. I'm not sure it's related, but it seem to happen if I first touch my palm to the screen before the pen. I uploaded a video here. 

I found another issue that sometimes deleting annotations can't be undone. This seems to work with the pen and highlighter tools and is related to the grouping of multiple lines into one annotation. Here are some steps to see it:

• Enter annotation mode
  
• Draw two lines
  
• Delete one of the lines
  
• Press 'undo', and the line will come back
  
• Delete both of the lines
  
• Press 'undo' and the lines don't come back
  

It seems like deleting part of the annotation (some of the line segments) can be undone, but not when the whole annotation is deleted. I haven't noticed this for other tools besides the pen and highlighter, but I haven't rigorously tested everything.

[MartinH]

I've found another case where the first pen touch does nothing, and this might be happening to me more often than the 30 second delay I mentioned in the previous post. 

If you do a pinch resize and don't remove your fingers, the next touch will be ignored. This doesn't sound like a problem, but pretty frequently the palm rejection isn't perfect and gets detected as a pinch zoom for a second before rejecting the contact. If this happens when I place my hand on the screen to write, the next pen touch is ignored.

[Zubersoft]

The video you sent is the same issue as your last post - in the video, you can clearly see the zoom that occurs when your palm touches the screen. You didn't disable the palm rejection setting in the annotation settings, did you? If not, you may just want to disable touch input while using the stylus, as that would resolve this issue entirely. My palm doesn't seem to cause zooming to occur - I'm not sure if that's just a difference in how we write. On my Samsung S8 Ultra, if I place two fingers down like a pinch zoom, don't move them, then release, my next stylus input works properly like I would expect. There is only one situation in which I can reproduce what you are describing - if I pinch zoom in and out, about 1 out of 10 times, the next S-Pen input does not work. So I will see if I can locate what causes that.

Thanks,
Mike