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

xr-mode-ui: Add explicit full screen mode #5464

Open
cmahnke opened this issue Feb 15, 2024 · 8 comments
Open

xr-mode-ui: Add explicit full screen mode #5464

cmahnke opened this issue Feb 15, 2024 · 8 comments

Comments

@cmahnke
Copy link

cmahnke commented Feb 15, 2024

Description:

This is a feature request.

Currently the button created by xr-mode-ui is depending heavily on feature detection, for Desktop Chrome this means, that it provides a full screen mode if no device are detected. This is a great feature.
My proposal is to make this configurable, so it can (additionaly) act only as full screen toggle on demand. Just to make things clear: I'm referring to the mode enabled by clicking the button with the arrows in each of the four corners.

I tried to force the mode with xr-mode-ui="enabled: true; enterVREnabled: false; enterAREnabled: false;" but this doesn't work.
Implementing it that way would made the requested feature a bit hidden, so there might be another XRMode, which could be named fs for full screen.

There is certainly demand for this, since there are several (mostly outdated) fullscreen components scattered over the the web.

  • A-Frame Version: 1.5.0
  • Platform / Device: Chome on Mac OS
@dmarcos
Copy link
Member

dmarcos commented Feb 15, 2024

Can you elaborate your use case? Seems a bit specific and it's a depart from expected behavior and A-Frame focus. Would have to be clear demand to justify maintenance.

Notice you can disable xr-mode-ui and use same code to derive your own fullscreen-mode-ui (Remove AR and VR parts). Should be easy and can publish on npm

@dmarcos
Copy link
Member

dmarcos commented Feb 15, 2024

Also on Mac OS you should always see fullscreen already. No WebXR support there

@cmahnke
Copy link
Author

cmahnke commented Feb 15, 2024

My consideration was that the code is actually already there, but it's not fleshed out yet: A extremely low hanging fruit.
Since I already tried the combination xr-mode-ui="enabled: true; enterVREnabled: false; enterAREnabled: false;" which implies the full screen functionality from my point of view, this might be even called a bug 😉.
The fall back (in case the APIs aren't there) provides the requested mode, disabling the undesired functionality manually does not.

The generalizes use case is to create a build in flat full screen mode. Maybe I should rename the issue?

The actual background (my usecase) was the fact that I had the impression that A-Frame doesn't work very well with the WebXR API Emulator. And I wanted to make sure it wont be enabled.

Since it's meant to be include in a web page it doesn't really matter what my platform is capable or not, actually I suspect users on other platforms as well.

@dmarcos
Copy link
Member

dmarcos commented Feb 15, 2024

What do you mean by? Not sure I understand

  The actual background (my usecase) was the fact that I had the impression that A-Frame doesn't work very well with the WebXR API emulator. And I wanted to make sure it wont be enabled.

By the way I recommend using more modern and up to date Meta WebXR emulator

xr-mode-ui component intent is just to provide VR and AR buttons and fallback to fullscreen if none of those modes are available. We can expand docs if not clear. Just a fullscreen button adds complexity and not sure if in scope.

@cmahnke
Copy link
Author

cmahnke commented Feb 15, 2024

Well, what I meant is just that I wanted to disable potentially / confusing (as in getting unwanted bug reports) misleading functionality.

Thanks for the hint, I'll try that one out.

Following that logic would require to remove the fall back full screen as well - it's current existence implies that it's in scope, otherwise it wouldn't be there in the fist place. It's basically about symmetry between the results of the API detection and the manual setup / parameter possibilities. So there is no need for a new button at all, just enable a possibility to force the fall back, maybe by setting enabled: true; enterVREnabled: false; enterAREnabled: false;.

@dmarcos
Copy link
Member

dmarcos commented Feb 15, 2024

What I mean if that if you have the emulator installed / enabled and you see the VR and AR buttons instead of fullscreen that's expected behavior since the emulator injects the WebXR API. That's a dev workflow and should not affect users. The extension can be disabled if not in use to get regular behavior

@dmarcos
Copy link
Member

dmarcos commented Feb 15, 2024

The more concrete question is. In what scenario you only want the fullscreen button and never the VR / AR ones?

@dmarcos
Copy link
Member

dmarcos commented Feb 15, 2024

enabled: true; enterVREnabled: false; enterAREnabled: false;.

The fullscreen fallback only applies if enterVREnabled and / or enterAREnabled can't be fulfilled because there's no WebXR API available in the system. If you disable the buttons fallback doesn't apply. As mention we can clarify in docs if unclear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants