Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase flexibility in choosing icon size #326

Closed
antodc opened this issue Apr 10, 2024 · 5 comments
Closed

Increase flexibility in choosing icon size #326

antodc opened this issue Apr 10, 2024 · 5 comments
Labels
duplicate A similar ticket already exists for this improvement request Request for an improvement to an existing feature solved This issue has been solved

Comments

@antodc
Copy link

antodc commented Apr 10, 2024

Thanks infinitely for this wonderful launcher!! It is almost perfect for me. It would be 100% fine if you could add the following three features (in order of importance in my opinion).

a) the possibility to choose among a more granular set of icon sizes
b) the possibility to set different sizes for the icons of the preferred apps and the apps in the drawer
c) the possibility to choose the number of columns in the app drawer

Thanks a lot again for your efforts!

@falzonv
Copy link
Owner

falzonv commented May 4, 2024

Hello,

Thank you for the suggestions, I'm glad you like the launcher!

Unfortunately, I made a mistake when designing the icon size setting which make it difficult to change now without breaking backwards compatibility (= transparently for users having already changed the setting).

Copy-paste from ticket #281:

Initially this setting was added because when using the launcher on a tablet, icons looked very small (phone size). My first plan was to make a toggle "Normal / Large" but then I discovered that the launcher could also be used on a TV and thought that even bigger icons would be needed for that case.

So I ended up using a slider with 4 positions numbered from 3 to 6 where the position is multiplied by 12 to get the icon size in dpi (which are then converted in pixels according to device density):
=> Position 3 gives an icon of 36dp (not really useful, but it makes the slider look better when the default value is selected)
=> Position 4 gives an icon of 48dp (icon size in the Android stock launcher, and default value in Discreet Launcher)
=> Position 5 gives an icon of 60dp (looks better than the default size on a tablet)
=> Position 6 gives an icon of 72dp (alternative for even bigger screens)

Thinking about it again, maybe the best solution would be to hide the current setting, create a new one, and implement a migration process between the two.

In order to avoid further mistakes, could you detail a bit more which granularity you would like?
(adding also @Yasen6275 for a second opinion, if you are still interested by this improvement of course)

Since we need to retrieve the current sizes for backwards compatibility, here are the options available:

  • 19 positions (internally numbered from 18 to 36), with icon size in dpi = position * 2
  • 13 positions (internally numbered from 12 to 24), with icon size in dpi = position * 3
  • 10 positions (internally numbered from 9 to 18), with icon size in dpi = position * 4
  • 7 positions (internally numbered from 6 to 12), with icon size in dpi = position * 6
  • 4 positions (internally numbered from 3 to 6), with icon size in dpi = position * 12 (current, for reference)

To have a more complete view of the final granularity, we would need to compute the icon size corresponding to each position in each scenario (*2, *3, *4 and *6) but I don't have the time to do it right now.
I am afraid 19 positions would be too confusing to select from...


Sorry points b) and c) will not be implemented, more details in ticket #314.

And sorry again for the late answer... in addition to my announce in ticket #314, I now also have repetitive strain injuries in both wrists and had to reduce a lot my computer activities, especially programming.

Best regards.

@falzonv falzonv added duplicate A similar ticket already exists for this improvement request Request for an improvement to an existing feature labels May 4, 2024
@antodc
Copy link
Author

antodc commented May 4, 2024

@falzonv Thank you so much for having found the time to answer my message! You still look quite active for this project. :-)
I would vote for the middle option, that is 10 positions. If possible, maybe it could be implemented with a drop down menu instead of a slider. Should you use a drop down menu, maybe also options 13 and 19 might be considered.
In any case, take your time and if and when you could implement this I would really be glad. In the meantime, I will keep enjoying your app as it is and I wish you all the best for your wrists. And for anything else.

@Yasen6275
Copy link

(adding also @Yasen6275 for a second opinion, if you are still interested by this improvement of course)

I would like to have maximum flexibility. Because on different screen sizes different size would be optimal for me.

On my current phone 36 is too small 60 is kind of big, 48 is also big but workable. My mom phone is on 60 but that's understandable on her age. I can see younger ppl with finer motor control and sight to go even under 36. Can we have digits as input or scrolling menu with digits like I've seen when entering date?

now also have repetitive strain injuries in both wrists

Get better. Have you tried split, vertically staggered keyboard? It's hard to adapt in the begging nut much better for wrists. Or so I've heard

@falzonv
Copy link
Owner

falzonv commented May 18, 2024

Hello @antodc, @Yasen6275,

Thank you very much for your feedbacks and kind words :-)

From technical point of view, using a dropdown menu instead of a slider is a much better idea than my plan from the above message, thank you @antodc for the suggestion!
It allows to define arbitrary values so that there can be, for example, more granularity around 48dp (default size from Android stock launcher) than 72dp. Adding new values would also be easier if needed in the future, I kind of regret not having this idea for the initial implementation, it would have been much simpler.

Thank you @Yasen6275 for the real life examples, I will think about it to see which intermediary values would be most relevant (probably something like 32 36 40 44 48 52 56 60 64 68 72 would be good to start with).

Regarding the digit input/scroll, this may also be an interesting option but I have to check what is available and how it would work (I try to use only the official Android preference library for better compatibility ; the only exception so far is the color picker but it is reused 8 times in the launcher so it worths the additional maintenance effort).

I never tried a vertical keyboard as they seemed quite expensive with mixed user feedbacks.
Aside having now better desktop ergonomics, seeing a hand therapist and doing daily wrists strengthening exercises, I also use Workrave to remind me of taking frequent breaks and recently discovered Talon Voice Control which looks very promising (altought it took a lot of time and the result still required many edits, I was able to use it to dictate most of this message).

Best regards

@falzonv falzonv added the solved (waiting publish) Issue solved, new release published soon label Aug 24, 2024
@falzonv
Copy link
Owner

falzonv commented Aug 24, 2024

Hello,

Thank you for your patience, this has been implemented in new release v7.6.0!
I will leave this ticket open until it is available on F-Droid (usually takes 4 to 8 days).

As you will see I went with the drop-down menu option and increments of 2dp (instead of 12dp increments in v7.5.0 and 4dp increments that I mentioned in my last message).

Best regards.

@falzonv falzonv added solved This issue has been solved and removed solved (waiting publish) Issue solved, new release published soon labels Sep 4, 2024
@falzonv falzonv closed this as completed Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate A similar ticket already exists for this improvement request Request for an improvement to an existing feature solved This issue has been solved
Projects
None yet
Development

No branches or pull requests

3 participants