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

[no squash] Split touch controls from UI #14749

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

okias
Copy link
Contributor

@okias okias commented Jun 12, 2024

  • Goal of the PR

Prepare for touch screen autodetection.

  • How does the PR work?

Split touchscreen controls from UI adjustment for touch screen devices.

  • Does it resolve any reported issue?

No. But prepares ground for auto-detection of touch input, where changes in UI would be undesired.

Yes, it does improve touchscreen experience and clarity of the TS code.

  • If not a bug fix, why is this PR needed? What usecases does it solve?

How to test

Check the UI settings, check the touchscreen settings.

@grorp grorp self-assigned this Jun 12, 2024
@grorp grorp self-requested a review June 12, 2024 15:12
@okias
Copy link
Contributor Author

okias commented Jun 12, 2024

Well, for UI, since Minetest has no TUI, UI implies always GUI. Anyway I'm ok with both.

@okias
Copy link
Contributor Author

okias commented Jun 12, 2024

Tested latest changes, no regression spotted.

edit: today I'll also run it again the mobile phone https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55520

@grorp
Copy link
Member

grorp commented Jun 12, 2024

Well, for UI, since Minetest has no TUI, UI implies always GUI. Anyway I'm ok with both.

There's one other (G)UI setting. That other setting is called gui_scaling, so we should use the term "GUI" for the new setting too to be consistent.

@grorp
Copy link
Member

grorp commented Jun 12, 2024

All commits after the first one should be squashed IMO, so that we have two commits in the end.

@okias
Copy link
Contributor Author

okias commented Jun 12, 2024

Tested on the phone, works exactly as expected.

Next thing I'm wondering now, is the ability to ask system for landscape mode and lock (as minetest in portrait mode has a squashed not-much-usable controls.. and it probably doesn't make much sense to do it flexible that much).

@grorp
Copy link
Member

grorp commented Jun 12, 2024

Next thing I'm wondering now, is the ability to ask system for landscape mode and lock (as minetest in portrait mode has a squashed not-much-usable controls.. and it probably doesn't make much sense to do it flexible that much).

Minetest on Android does that, how would we do it on Linux?

@grorp grorp added @ Startup / Config / Util Android UI/UX Supported by core dev Not on the roadmap, yet some core dev decided to take care of this PR labels Jun 12, 2024
Copy link
Member

@grorp grorp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Tested on Android. Needs squashing as mentioned above.

This is the first half of the changes from #14542. Thanks for splitting them into a separate PR.

I don't know what happened to the feature freeze and release plans btw ¯\(ツ)

to avoid confusion between touchscreen-related settings that affect GUIs
(formspecs) and touchscreen-related settings that affect the touch controls
(TouchControls / formerly TouchScreenGUI)
…ouch_gui

touch_gui provide adjustment to the interface, so it's more touch
friendly

Signed-off-by: David Heidelberg <[email protected]>
@okias okias force-pushed the split-touch-controls-from-UI branch from 8883d87 to e467fa5 Compare June 12, 2024 21:50
@okias
Copy link
Contributor Author

okias commented Jun 12, 2024

Next thing I'm wondering now, is the ability to ask system for landscape mode and lock (as minetest in portrait mode has a squashed not-much-usable controls.. and it probably doesn't make much sense to do it flexible that much).

Minetest on Android does that, how would we do it on Linux?

So far I've been told we would need new Wayland extension for that, which make sense. TBD for now.

@grorp grorp changed the title Split touch controls from UI [no squash] Split touch controls from UI Jun 13, 2024
@okias
Copy link
Contributor Author

okias commented Jun 21, 2024

@sfan5 what do you think?

@grorp
Copy link
Member

grorp commented Jun 21, 2024

In case somebody is wondering "why do we need this?": It makes it possible to enable mouse/keyboard controls on your phone without menus becoming way too small. An example of what currently happens with enable_touch = false on my phone:

way too small mainmenu on Android

This PR would be reasonable to merge before 5.9.0.

@sfan5
Copy link
Member

sfan5 commented Jun 21, 2024

@sfan5 what do you think?

Seems useful but haven't looked at the code closely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Android One approval ✅ ◻️ @ Startup / Config / Util Supported by core dev Not on the roadmap, yet some core dev decided to take care of this PR UI/UX
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants