Closed foxjaw closed 4 months ago
Alternative: Save the current pie layout when settings screen is opened & reset to that one if the app that was dragged in is dropped on the cancel icon (hope the explanation is clear)
Neat little trick to rotate the drawer (move all icons by one position): Hold an app that is already in the drawer and move it around the drawer once (CCW for rotating all apps CW and vice versa)
@einmeterhecht Yup that behaviour I already noticed. Hold one shortcut & revolve it in the opposite direction of the pie rotation (& leave that app in it's previous position).
As far as locking the layout, I think preventing the editor layout on holding is the only non-complicated way.
Hm, now that there's an icon above the app listing to enter the settings, I could add another icon there to enter the pie editor, and disable the drag and drop entering by default…
Also I should really mention how to move all icons by one position.
That would be a good idea too.
And have the edit icon on the left side of the search bar (for symmetry)
If you do that, we can also use some other function for holding apps in drawer (such as appinfo page of that app)
I was about to ask for this feature, as making accidental changes is a recurring problem for me.
Below is my perception, and theory how/why it occurs for me - maybe it is a useful detail.
When I have started using Pie Launcher couple of months ago, I had to consciously learn to tap properly without sliding (which is sometimes still hard) to avoid accidentally entering the editor - it occurred all the time. I have learned to be more precise, but I was using this mobile for 3+ years, and I have not had problems with taps before in other apps.
My perception is that the launcher is more sensitive to taps vs swipes/holds than other apps. So I think it is related to how touch events are treated, how much precision is required (sometimes too much in my case). I think #25 was raised due to a similar experience.
Precision might also be affected by humidity level and temperature, because I have sometimes this problem repeatedly, then not for a while - and I have another touch-related problem with launching apps: in the winter (dry+cold), I have hard time opening applications outside, as the app icons in the app drawer are resisting responding to touch events. I have enabled developer options + "Show taps" and touch events are visible, so they are recognized somewhat (can see transparent discs growing), but not long enough to fully register (longer remaining small disc). Interestingly I can use the keyboard, without problem, just selecting the icons are problem.
@e3krisztian I have no touch issues with current implementations tbh. Are you talking about app drawer spawn through tap ?
Yes, app-drawer tap is not working sometimes. Sorry if it is another problem, I did not want to distract this feature request with another problem - locking the layout is important feature for me, I just thought its root is in the precision required.
Precision in the sense the amount of milliseconds required for tapping to open the drawer right ? On mine, I have to tap & release very quickly. https://github.com/markusfisch/PieLauncher/blob/0d7ffadb930da135eb11b7676575bbcd879f9fe7/app/src/main/java/de/markusfisch/android/pielauncher/activity/HomeActivity.java#L122 If I exceed like even 100 milliseconds, then it's considered hold. Is this what you're referring to ?
@foxjaw No, the app drawer can be activated, it is inside the app drawer, when there are lots of icons, sometimes I can not start them, or hardly, even if tapping multiple times. I considered it related to touch sensitivity and affected by humidity level - that's why I mentioned it. I will open a separate issue about it, when it becomes my main problem and have enough experience with it.
I think the default touch timing parameters are not always working for me, but having some guard against unintentionally entering edit mode will help a lot eliminating problems.
The rotating trick mentioned above have already helped me! :-)
@e3krisztian Thank you very much for the detailed description! 👍 That helps a lot in solving this problem!
Unfortunately, this is something that I can hardly reproduce on my own devices, perhaps only with my own fingers, so I can only solve the problem with your help.
In theory, technically, (in the app list) the app recognizes all touches as taps that move less than [ViewConfiguration.getScaledTouchSlop()](https://developer.android.com/reference/android/view/ViewConfiguration#getScaledTouchSlop()) and that have lasted less than [ViewConfiguration.getTapTimeout()](https://developer.android.com/reference/android/view/ViewConfiguration#getTapTimeout()). These threshold values are provided by Android and reflect the respective default values (which may be influenced by user settings or the device manufacturer). So the taps in the app list should feel exactly the same as anywhere else - which is obviously not the case everywhere 😞
Sorry about this. I am trying to find a solution.
@markusfisch sure, I will help if I can.
As it is standard delay, I have looked at my phone, and in the Settings
/Accessibility
/Touch and hold delays
is set to Short
, but I do not remember ever changing it, it is probably at default. I will try setting it to Medium, Time to take action (Accessibility timeout)
is at Default, also animations are turned off there (intentional choice).
However I am also experiencing what @foxjaw mentioned - entering the app-drawer can be tricky sometimes, which is hard-coded delay(?)
entering the app-drawer can be tricky sometimes, which is hard-coded delay(?)
As of now, yes. https://github.com/markusfisch/PieLauncher/issues/67#issuecomment-1882701115
Although Mark can bring it into userspace through configuration. Right now, there is very limited configuration, & we expect it to increase in the number of configs in future.
@e3krisztian Ah, that's interesting! I'm really curious to see if "Medium" improves/corrects the responsiveness in the app drawer…
Entering the app drawer works with the exact same methods, which is triggered here.
The snippet @foxjaw mentioned above (and the hard-coded delay in it) has nothing to do with registering taps, but is only relevant when returning to the home screen using the home button, which becomes clear with the corresponding comment on top of that line, see:
Ah my bad. Ignored comment documentations I'm a terrible at reading code.
@e3krisztian Please try version 1.17.1 which improves touch detection. I hope it works better now.
@foxjaw Previous versions had a bug for the long press in the app drawer, which made it too easy to enter the editor. Version 1.17.0 fixes this, and I believe there is no need for locking the menu anymore. If it still doesn't feel correct on your device, please let me know.
Unfortunately I have to wait for fdroid release due to the signature mismatch on GitHub release.
@markusfisch I have installed the new version from the Play Store, and tried to use it, but I had problems with it: I have been able to enter edit mode only once, and it was not easy - I do not even know how I did it, in general I could not enter edit mode.
The way it looks is, that when I hold an icon in app-drawer, it becomes selected visibly (maybe even grows a bit?), but can not move it in its state to enter edit mode.
I went back to the F-Droid 1.16.1 version.
Regarding Accessibility
/Touch and hold delays
, Medium
setting made no difference to me, so it is not something relevant now.
Please ignore my words above, I have reinstalled the new 1.17.1 version to have another go, and now I can confirm, that entering the edit mode accidentally is very hard.
It can be entered by looong-pressing an app-icon in the app-drawer. I just was not patient enough to press it this long.
I like this solution for entering edit mode!
@e3krisztian How long btw ? (in seconds)
I can count to 2, so it is about 1 second. Feels long enough to fool me initially, that I can not enter edit mode at all.
Just keep holding the app icon for 1-2 sec to enter edit mode!
@markusfisch thank you for making this change!, I think it is a big usability improvement, and solves the accidentally entering the edit mode problem. I have looked at the code, it required some thinking over the timings - I do not understand the code fully, but it was not a trivial change.
When I understood what the change in behavior is, I started worrying about existing users - it was the most discoverable feature (because it was too easy to enter), and it has changed in a way, that fooled me into thinking it is not working at all. Adding a layout lock could have been a safer step, but the current long-press way is much-much better than having a locking UI, once I know it works this way.
@e3krisztian Actually, it wasn't really a change, but a bug fix 😉 It was always supposed to work like this. Previous versions had this bug where (over)scrolling would incorrectly interfere with checking the touch [slop](https://developer.android.com/reference/android/view/ViewConfiguration#getScaledTouchSlop()) (which is the distance a touch can wander before we think the user is scrolling). This was fixed in https://github.com/markusfisch/PieLauncher/commit/499d2326587bed9f5b35126820b9c7243f626a4e
The time to detect a long press always was whatever [ViewConfiguration.getLongPressTimeout()](https://developer.android.com/reference/android/view/ViewConfiguration#getLongPressTimeout()) returns. The (configurable) system default.
But I just realized why it feels longer now: Version 1.17.0 also changed the touch feedback when long pressing an icon in the drawer from the ripple effect to just magnifying the icon under the touch.
Unfortunately, the magnifying can be hard to notice because it's happening somewhat obscured by the finger. So intially, a user doesn't see anything happening, which is bad. Before that change, the ripple effect was an immediate feedback, and I will bring that back in the next version!
Sorry for the confusion, and thanks for bringing that back to my attention! 👍
@markusfisch I have installed the new 1.17.3 version, and it is much more eager to enter edit mode. I feel it is too easy to enter and mess up the current pie-menu again :crying_cat_face:
With this version I would still prefer either a lock, or making the enter-edit-mode-delay longer - either a multiple of [ViewConfiguration.getLongPressTimeout()](https://developer.android.com/reference/android/view/ViewConfiguration#getLongPressTimeout()) or independently set.
@markusfisch I think you should consider edit mode button in app drawer, as you mentioned in https://github.com/markusfisch/PieLauncher/issues/67#issuecomment-1871113882. I don't see any other proper way.
I'm still on the last fdroid version 1.16.1 due to signature mismatch, hence can't know what you've changed.
I am not sure if the current long press would still cause problem for me, as I got used to using it, but my feeling is, that unless the intention is to edit the menu all the time (thus no muscle memory), I would prefer edit mode to be harder to enable.
I really liked the 1.17.1 very long press to enter edit mode, but I am afraid it was an unintended "feature", and would be harder to discover/follow by existing users.
Either the enter delay being configurable, so that it can be set to long enough or an explicit edit mode button would be a good path forward.
@markusfisch you mentioned that long press timeout is a system configurable value, I have looked around and have not found a way to influence it. According to what I saw on the net, it is also about half seconds (500 ms) by default, which should be enough, but that is not my experience in this case, and people are asking about how to make it longer.
I actually suggest long press to open appinfo page, instead of editor.
And use the search panel in app drawer to include a button to access the editor mode.
Suggesting this, because I'm a former user of mlauncher, which is a very lightweight launcher with no icons. Just appname list. That's how it use to work in there.
@e3krisztian Well, that's really interesting: how the touch feedback alters how it feels. The long press duration never changed! 1.17.3 just added the immediate touch feedback. Hm. Very interesting! And very valuable feedback! Well appreciated!
So, it's probably better to remove the touch feedback again… 🤔
you mentioned that long press timeout is a system configurable value…
Yes, it should be here:
On my devices, with default settings, [ViewConfiguration.getLongPressTimeout()](https://developer.android.com/reference/android/view/ViewConfiguration#getLongPressTimeout()) returns 400 (ms). Just for reference.
Generally, I don't think it makes sense to make this value configurable in the app. Rather, the long press should feel and work exactly like everywhere else in the system. This is how all other launchers do it, and how it works in all other apps. If it's not feeling right yet, I will rather work on that.
@foxjaw Sorry for f-droid lagging behind. Unfortunately there's nothing I can do to trigger an update, so we just have to wait until they update to the latest version.
I actually suggest long press to open appinfo page, instead of editor.
Yes, I can understand that, but performing a different action for a long press wouldn't help if it's (felt) too sensitive. Then, instead of jumping into the editor by mistake, you'd simply jump into app info and would be equally annoyed 😉
So I think the top priority should be to make the long press feel right.
Which doesn't mean I'm not open for this idea. In fact, I already tried it, but decided to revert it for now, because I feel this would not solve the root problem.
Also, off topic, mlauncher looks really nice too! Didn't know it yet! Thanks for mentioning it!
I believe you should have a beta / debug version separate from release version ? It should solve this issue where I can install test apk with different app_id simultaneously beside regular one.
If everything set, merge the test branch into the main.
@foxjaw There is already a Beta channel available: https://play.google.com/apps/testing/de.markusfisch.android.pielauncher
In which version 1.17.4 should become available in the next few hours or so. Alternatively the latest version is always available from GitHub directly here: https://github.com/markusfisch/PieLauncher/releases/tag/1.17.4
Please note that f-droid is using their own signature (which is part of their security/transparency model to make sure the app is really built by them), so these options are incompatible with f-droid installs, unfortunately.
@e3krisztian Version 1.17.4 delays the touch feedback a bit… feedback is always welcome!
@markusfisch thank you for working on this! I have checked out both the beta channel and the 1.17.4 version.
I have the feeling I finally understood something I do and expect, because unfortunately I do not feel any improvement between versions (apart from the short lived 1.17.1 behavior):
I think my problem is 2-3, that is, I can not start the app, because of variance due to the device not recognizing the touch/tap the same way every time (1), due to this I quite frequently try to hold it longer, and I enter the dead touch area between start-the-app and edit mode.
I have looked around, and I have the feeling, that other apps (gmail, browsers on links) and even the system (e.g. navigating settings) are behaving differently and consider the period between the tap-time and the long-press time as tap.
Is the dead period intentional to cancel an app start? Could movement be used to cancel an app start instead?
@e3krisztian Thank you so much for your valuable feedback! Your precise observations have helped me a lot to better understand what is going wrong!
Is the dead period intentional to cancel an app start?
No, this dead period was indeed wrong! I misunderstood that [ViewConfiguration.getTapTimeout()](https://developer.android.com/reference/android/view/ViewConfiguration#getTapTimeout()) specifies the "duration […] we will wait to see if a touch event is a tap or a scroll" - not when a tap times out. In fact, a tap never times out, of course, it only becomes a long press 🙈
So that was implemented incorrectly, but is fixed in Version 1.17.5, which should very soon become available in the beta channel.
@markusfisch I have checked out the 1.17.5 version and so far this version works perfectly for me - thank you!
Sometimes I still enter edit mode instead of starting the app, but I think it is more due to my curiosity on how long I could keep holding an icon in the ripple effect without entering edit mode.
@foxjaw Sorry, I have hijacked your issue, and the original issue looks like resolving in a different way than locking the layout, which you might still prefer, and which I think still has its merit.
There is already a Beta channel available: https://play.google.com/apps/testing/de.markusfisch.android.pielauncher
@markusfisch I'm sorry but I'm not talking about beta channel. It's about app_id
. appid's of both play store & f-droid are same, with different signature so can't install.
Sorry, I have hijacked your issue, and the original issue looks like resolving in a different way than locking the layout, which you might still prefer, and which I think still has its merit.
@e3krisztian I donno mate. App needs to be in f-droid for me to decide how to proceed further. Although, I'm adamant for an actual edit button instead of hold shenanigans.
@foxjaw I know, and I'm really sorry that f-droid hasn't updated yet. Curiously, I can see the latest version in f-droid's metadata 🤔 Maybe I can find out what's going on here.
The application ID of an existing distributed app cannot be changed, neither in Play Store, nor in f-droid. I could only publish a new, additional app, which wouldn't make too much sense.
@e3krisztian Thanks for testing it so quickly! 👍 And happy it's working now like it should!
Tbh, @e3krisztian's description says you've extended the hold timing. I'm not sure if that's the solution. Because the hold action can still be activated by human error whether it's short or long.
A manual edit button would make sense. It's much more UI intuitive, understanding & avoids involuntary behaviours.
A better way, would be to have a settings configuration that disables the "hold to enter pie editor" (which is why I've titled this issue as Lock the layout instead of extend hold timing to enter pie editor)
I agree with the reasoning of @foxjaw that explicitly locking the layout would be a welcome feature still.
Although entering the edit mode accidentally causes less problems (for me at least) with the recent changes, it is somewhat too easy still for those of us who prefer a more stable menu.
Version 1.18.0 adds the "Press icon to add" setting, which allows you to extend the duration of the long press (select "Longer") or even try a pop-up menu instead of adding the icon directly to the pie menu (select "Show menu instead").
@foxjaw The menu option should be roughly what you wanted. For me, this somewhat breaks the concept of adding items to the menu, and also the elegance of simply dragging an app to do something with it. But if you really like it that way, I'll happily keep that option. So I would highly appreciate your feedback on this.
I've tried 1.18.0 on another spare phone btw.
The menu functions in a weird way. To enter into editor mode, you have to first add the app you holded on. What if the user just wants to shuffle the existing layout ? It makes this complicated. Had to add some app temporarily & then remove it from the pie, just to shuffle ? Not cool btw.
I actually preferred edit button in the search bar to bring editor. It also negates the need for alternative editor ways.
I would still not prefer changing the description of this FR. Because we're trying to modify the editor mode experience, instead of introducing a concrete lock mechanism.
My only aim of this FR:
MAKE EDITOR MODE DIFFICULT TO ACCESS (without modifying the current layout)
How about using biometrics / lock pin / phrase to access the editor ? The actual way of locking editor mode.
The menu functions in a weird way. To enter into editor mode, you have to first add the app you holded on. What if the user just wants to shuffle the existing layout ? It makes this complicated. Had to add some app temporarily & then remove it from the pie, just to shuffle ? Not cool btw.
Oh I see 🤔 That is something I'm very used to when entering the editor by dragging an icon, so it didn't occur to me that this could feel cumbersome. In an earlier attempt to solve this issue, I already changed the gear icon in the search bar to a pen (that leads to the editor then) when the pop-up menu option is active. I will bring that back. Makes much more sense 👍
MAKE EDITOR MODE DIFFICULT TO ACCESS (without modifying the current layout)
So you really want a locking mechanism! Apparently I misunderstood your original request 🙈 I thought you wanted to lock the editor because it was too easy to enter. Which it really was, because of that bug from above, but is no longer. It should be nearly impossible to enter the editor by mistake now (especially when you choose the "Longer" option for "Press icon to add").
But you seem to have a different use case?
The lock mechanism is needed not just to make editor difficult to access, but also protect messing up of the pie when I gave my phone to a layman.
In the above case where "long press to add", a layman do not know what he's doing. If there's a dedicated "edit button", that itself describes that editor mode is to be accessed.
On the contrary, even that is not considered the layout locking. For an example, Lawnchair Launcher has a "lock the desktop" option in it's configuration that completely removes drag & drop, as well as other buttons in the whole launcher interface that cause modifications to the desktop.
In this case, the only way to modify the desktop (pie in our case) is to disable the lock toggle from settings, then you can access the editor.
TLDR; Introduce a toggle in settings that disables access to the editor completely.
This is what I actually call locking of the layout.
And to hide the apps, one must have to enable "show menu instead" even if you like hold to open editor.
See mark, your work is amazing. But with huge inconsistencies. I hope you plan UI/UX of your project first, then jump into the coding. That would be amazing.
TLDR; Introduce a toggle in settings that disables access to the editor completely.
Version 1.18.1 has now the option "Locked" for "Press icon to add" which should be just what you want.
And to hide the apps, one must have to enable "show menu instead" even if you like hold to open editor.
Fixed in https://github.com/markusfisch/PieLauncher/commit/21d7336949238bb4dc10f557d9f17771b35c2082
Besides, my name is Markus, not mark, and I better don't tell you what I think of that "huge" inconsistencies part 😉
Must needed, because I accidentally holded the apps in drawer that were already placed in pie & completely changed the locations. This also disrupts the directions & rotates the pie that I've set up.
Layout lock idea is to avoid drag & drops inside drawer. This lock toggle should be enabled/disabled from configuration.
PS
Locking the layout might increase steps to re-edit the pie but very useful for those who setup the pie once & for all.