markusfisch / PieLauncher

Android home screen launcher that uses a dynamic pie menu instead of tables of icons.
https://play.google.com/store/apps/details?id=de.markusfisch.android.pielauncher
MIT License
290 stars 39 forks source link

Lock the layout #67

Closed foxjaw closed 4 months ago

foxjaw commented 6 months ago

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.

einmeterhecht commented 6 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)

einmeterhecht commented 6 months ago

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)

foxjaw commented 6 months ago

@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.

markusfisch commented 6 months ago

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.

foxjaw commented 6 months ago

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)

e3krisztian commented 5 months ago

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.

foxjaw commented 5 months ago

@e3krisztian I have no touch issues with current implementations tbh. Are you talking about app drawer spawn through tap ?

e3krisztian commented 5 months ago

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.

foxjaw commented 5 months ago

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 ?

e3krisztian commented 5 months ago

@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! :-)

markusfisch commented 5 months ago

@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.

e3krisztian commented 5 months ago

@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(?)

foxjaw commented 5 months ago

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.

markusfisch commented 5 months ago

@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:

https://github.com/markusfisch/PieLauncher/blob/e16c158ca6fad3f2abf00d89f9b1e979eeb5cc5c/app/src/main/java/de/markusfisch/android/pielauncher/activity/HomeActivity.java#L118C6-L122

foxjaw commented 5 months ago

Ah my bad. Ignored comment documentations I'm a terrible at reading code.

markusfisch commented 5 months ago

@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.

foxjaw commented 5 months ago

Unfortunately I have to wait for fdroid release due to the signature mismatch on GitHub release.

e3krisztian commented 5 months ago

@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.

e3krisztian commented 5 months ago

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!

foxjaw commented 5 months ago

@e3krisztian How long btw ? (in seconds)

e3krisztian commented 5 months ago

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!

e3krisztian commented 5 months ago

@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.

markusfisch commented 5 months ago

@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! 👍

e3krisztian commented 5 months ago

@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.

foxjaw commented 5 months ago

@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.

e3krisztian commented 5 months ago

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.

foxjaw commented 5 months ago

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.

markusfisch commented 5 months ago

@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:

  1. Open your device's Settings app .
  2. Tap Accessibility and then Touch & hold delay.
  3. Select Short, Medium, or Long.

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!

foxjaw commented 5 months ago

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.

markusfisch commented 5 months ago

@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!

e3krisztian commented 5 months ago

@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):

  1. sometimes I have difficulty due to environmental conditions to perform and get a tap recorded
  2. due to the above I sometimes fat-finger, and overstay the tap
  3. between tap and long-press there is a dead time, where I again can not start the app I want
  4. there is a ripple effect, which is in the dead region, the app would not start with the ripple going on
  5. I do not register the ripple effect as a warning to enter edit mode, and because I can not start the app by a tap, I wait for it to end

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?

markusfisch commented 5 months ago

@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.

e3krisztian commented 5 months ago

@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.

foxjaw commented 5 months ago

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.

markusfisch commented 5 months ago

@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!

foxjaw commented 5 months ago

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)

e3krisztian commented 5 months ago

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.

markusfisch commented 4 months ago

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.

foxjaw commented 4 months ago

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.

markusfisch commented 4 months ago

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?

foxjaw commented 4 months ago

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.

foxjaw commented 4 months ago

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.

markusfisch commented 4 months ago

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 😉