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

Added support for fullscreen options and proper fullscreen behaviors in macos #473

Closed
3 tasks done
edwin0cheng opened this issue Apr 19, 2018 · 6 comments
Closed
3 tasks done
Labels
D - average Likely as difficult as most tasks here DS - macos P - normal Great to have S - platform parity Unintended platform differences

Comments

@edwin0cheng
Copy link
Contributor

edwin0cheng commented Apr 19, 2018

This is a tracking issue for improvements of PR #465 :

  • Currently disregards whatever monitor is passed for setting fullscreen, always using whichever monitor has the keyboard focus. enterFullScreenMode should work for this, but it appears to be absent from core-foundation.
  • Similarly, get_current_monitor always returns the currently focused monitor, rather than the monitor the window is on. CGGetDisplaysWithRect could be used to find the monitor that the majority of the window is on. But it is absent from core-foundation too.
  • We should let user to control the FullScreen Options by expose it in WindowBuilderExt.

Here is the related PR for in core-foundation:

And related discussion: #460 (comment)

@francesca64 francesca64 added D - average Likely as difficult as most tasks here P - normal Great to have S - platform parity Unintended platform differences labels May 6, 2018
@francesca64
Copy link
Member

Is anything else blocking this? If you don't have time at the moment, I'd be happy to implement this.

@francesca64
Copy link
Member

Turns out that we don't need CGGetDisplaysWithRect at all (and using it correctly with DPI and coordinate spaces is tricky). All it takes is msg_send![window, screen]!

@francesca64
Copy link
Member

I've only addressed get_current_monitor. #521

enterFullScreenMode works pretty differently from toggleFullScreen. It pops our view out into a "private" fullscreen window, which not only means our window delegate's windowDidEnterFullScreen/etc. isn't triggered, but we also don't get events at all. If you fullscreen to a different screen than the window is on, then the window remains visible where it was in addition to having the fullscreen view.

Getting that to work correctly seems like it will be involved, so I'm not presently up to pursuing this further.

@edwin0cheng
Copy link
Contributor Author

Thanks for your help !!

  • The main problem is, i found that i do not have another screen to let me implement/test these features. Have to wait until i come back home next month. 😅

  • Actuallly i did not know how enterFullScreenMode works, but would it involve willUseFullScreenPresentationOptions:? If so, we can set the bookkeeping data there too. On the other hand, if using enterFullScreenMode is that complicated, do we have any other way to do it ? The goal here is choosing which monitor to go to fullscreen. Although google-fu failed to find any information about it, would it possible to move the NSWindow to another screen first, and call toggleFullScreen ?

@francesca64
Copy link
Member

You can supply the same options to enterFullScreenMode (and more). It should work fine to just move the window and toggleFullScreen, and it's at least better than nothing.

Optimistically, enterFullScreenMode isn't that complicated to work with, and I'm just not very familiar with Cocoa yet. It does have some advantages, i.e. it fullscreens without the transition animation.

@madsmtm
Copy link
Member

madsmtm commented Sep 8, 2022

It seems like this issue has been long fixed, please reopen if that's not the case

@madsmtm madsmtm closed this as completed Sep 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D - average Likely as difficult as most tasks here DS - macos P - normal Great to have S - platform parity Unintended platform differences
Development

No branches or pull requests

4 participants