Do Not Remap Not Working w/ Launch App Shortcut

[githubsterer]

Developer TODO (don't remove)

• update documentation

When I create a Key Map from a Tasker shortcut (unrelated to volume) and set the trigger to a single press of either volume key, the action runs fine but has two odd things going on. One, the Do Not Remap doesn't work, meaning the volume key graphic does not appear and presumably does not lower, and two, instead of getting one vibrate as with all the other key maps, it is vibrating twice, and there are no vibrations in the Tasker task. Interestingly, when I set the trigger to a sequence of volume up and then volume down neither of these problems happen.

[githubsterer]

Update. On the last issue, when both volume keys are set as triggers in sequence, there is only one regular vibration, as there should be, but strangely, even though both are set for Do Not Remap, unit the first key plays through. So if the sequence is up and then down, only the up volume shows and vice versa.

[githubsterer]

Rather than delete this post entirely and redo, I'll leave it to you to write it better, but here's what happening after testing further. It has nothing to do with the type of action, but a collision between any short press trigger of the same key that is also used in other variations like long press and double press.

In that situation, there are always two vibrations for each of these key maps instead of the normal one (all of my key maps are set to vibrate) and the Do Not Remap doesn't work on any of them, so in this case the volume keys cease to work.

The cause of this is the short press trigger because this is the first time I've used the short press trigger and it's also the first time these issues came up.

Pretty serious bug I think.

[githubsterer]

It's even worse testing further. Even if there are only two overlapping triggers of long press and double press, the Do Not Remap option breaks. So it has nothing to do with the short press, it's just any trigger with more than one key press combo.

But it's the short press for some reason they causes the double vibration.

Altogether, the whole remapping experience is awkward (nothing to do with you) because at least on the Samsung newer phones the only programmable buttons are the up and down volume, and there's obviously an inherent conflict between an action and the volume adjustment because in nearly every case you don't want both performed at the same time.

So when I set the up volume key to take a screenshot, it's just weird to perform that action and then have the actual volume change, and obviously if all I want to do is change the volume I'm not interested in taking a screenshot.

This is especially the case with the long press because you almost never want to have that creating havoc with your volume as you perform another task. It's bad enough having the volume change at all but there's so real way around that without losing the action or volume control entirely. But then you've also lost the ability to quickly lower the volume with a long press even when you want that.

In short none of this is ideal. I suppose a semi solution would be to then add volume up and down actions to a double or long press, but then you've used up those slots for that and not actions.

It's just a UI problem without any really good solution, except maybe the buttons idea you're working on, but even that will never have the same immediacy of a physical button because it will take at least a couple of steps to perform.

The absolute best implementation of the soft button approach has been the OHO+ swipe system because you do get immediacy than, for example, the edge panel which takes multiple swipes to just get to where you need.

Would have been nice to use the side power button but that also seems impossible. What we need is a phone with an entire side full of physical buttons!

[githubsterer]

I haven't quite thought this through, but maybe the solution would be to have a safe harbor designated where all the key maps are temporarily disabled in order to get to your single and long press volume adjustments.

Like maybe your home screen, which you can get to quickly, or recent. So if you're in Chrome or whatever and all of a sudden you need to change to volume, you go to the home screen, at which point the key maps give way to the volume controls as they normally work.

This would need to be an option, obviously, not forced on everyone.

Not great, but a solution nonetheless to an otherwise vexing problem.

[githubsterer]

So you actually have something like that already built in with constraints where you can disable the action when a certain app is in the foreground (but I don't see how you could designate the home screen since that's not an app) and it doesn't quite do what we need, but they might be because of the bug above. Meaning, that it does turn off the action but the original functionality isn't working.

That's the idea more or less, however. But rather than buried in constraints that need to be set for each key map. have it as an independent universal option that completely disables the key maps and does not rely on any Do Not Remap setting.

[githubsterer]

Well, well...

I actually got this to work using this setting, and once I disabled all other down volume key maps but the long press one (because of the bug above) switching to the home screen (any screen) does exactly as described.

Maybe everybody knows this and I'm late to the party, and I still think this could be fine tuned to apply universally, but in concept something like this makes the app much more user friendly.

The only downside, obviously, is that the key map won't work on the home screen, which might be a deal breaker for some people. Perhaps there's another hidden system app in that list that can be used instead. Or maybe you have a special dummy Key Mapper Safe Harbor app used for that purpose, but I'm not sure that's as convenient as the home screen since it's no easily accessible, because the entire point is to be able to quickly change the volume.

I need to see how all this plays out once the bug is fixed but in the meantime, adding the same constraint to each key map of the same button fixes that also, by disabling it.

[githubsterer]

FINAL UPSHOT FROM ALL THIS:

1. There's a bug when there are multiple key maps (at least two) using the same button but different press types, where the single press action vibrates twice and not once when vibration is turned on, and where the Do Not Remap doesn't work at all for any of them.

UPDATE: the double vibrate occurs in every version of the same key trigger as long as one of them is a also single press. So if you only have triggers for long and double presses on the volume down button, there's only one vibration in each case. Once the single press is also added as a trigger (not in the same key map but even as an entirely separate key map) then all of them exhibit the double vibrate.

UPDATE: To reiterate, I am not talking about having multiple triggers of various press types inside the same action (though I suspect it happens there as well) I'm talking about completely separate key maps, with each using a different press type for the same button.

2. Adding a constraint of when One UI Home is not in the foreground solves the longstanding inherent conflict between having to use Do Not Remap in order to retain the original functionality while also performing a separate action, thus eliminating the unintended result of either having to change the volume when it's not needed, or having to perform the action just in order to change the volume.

UPDATE: I'm now seeing that this constraint also works when you just get to the Recents page which is quite nice and a better choice than the home pages, but I don't see any way to choose just that and not the other since they are both apparently part of the One UI Home app.

3. There is perhaps an even better way to accomplish this without disabling actions on the home screen, by either identifying a better hidden system app for the constraint, or building this feature into the app as a universal separate option.

UPDATE: There is nothing in the current app constraints list except for One UI Home that works, and that would include all Home and Apps screens plus the Recents screen. The only idea I can think of to further refine this would be to add another constraint based upon text found on the screen. In this way by combining both constraints, you could limit it to the Recents screen by including some text unique to that page like the "close all" button or something like "active in background" .

[jambl3r]

Thanks for putting this all together. I'll investigate and make sub-issues where I can reproduce the bugs.

[githubsterer]

My pleasure. Here to help if you need anything. Feel like we're on the cusp of a substantially better app functionality.

[jambl3r]

Could you clarify what specifically the bug is with the app shortcut? Or is it now covered by the two issues #1507 and #1509 ?

[githubsterer]

The remaining issue is a feature request to better facilitate the ability to use the original button functionality without the Do Not Remap feature that effectively doubles up and does its original function after the key map runs, which is a naturally awkward occurrence because it either changes the volume needlessly when, let's say, you're taking a screenshot, or it forces you to take a screenshot to get to the volume control.

As described above, I have figured out how to work around this by setting a constraint that stops the key map from working when on the home, apps, or recents screens, which is a great way to you quickly get to the volume control undeterred by the key map.

[githubsterer]

I would just like to see a more robust implementation of this idea so that you wouldn't have to set at the key map level, and you could refine which screen to be used as your safe zone. In my work flow, a quick flick to the Recents screen is all I would want so they the other screens remain unaffected. Currently using the OneUi Home app in the constraints bundles all of those screens together.

[githubsterer]

Even with this implementation, the usability problem is still very profound and I am curious how others work around it. Under normal circumstances, flipping to the home or recents screen to casually change the volume is no big deal, but I was just on a phone call and needed to change the volume and couldn't without taking a screenshot, so in cases like that you cannot be flipping around to other apps to make it work. If the only way is to constrain from every possible app where volume plays a role (WhatsApp, You Tube, Chrome, etc.) then the key map has very little use. i wish there was some kill switch that could be quickly accessed to do this.

[githubsterer]

I suppose the correct way is to build a list of constraints around audio actions versus specific apps but might be easier to make those into defaults, or an option to do they, so they wouldn't need to be applied manually to each key map.

[jambl3r]

I would just like to see a more robust implementation of this idea so that you wouldn't have to set at the key map level, and you could refine which screen to be used as your safe zone. In my work flow, a quick flick to the Recents screen is all I would want so they the other screens remain unaffected. Currently using the OneUi Home app in the constraints bundles all of those screens together.

So is the question really if we can add 'on recents' as a constraint?

[githubsterer]

Yes! That would be awesome. Nice how you can reduce 1,000 words into 14 :-)