[Feature] Support Creation of Windows at Specified Monitor

[ndianabasi]

Description:

This PR implements support for multiple monitors by allowing the user to specify the coordinate where the window should be rendered from.

• This is implemented by providing a new method showAtPos which receives the x and y screen coordinate of for the window.
• If the screen coordinate correspond to a point on a secondary screen/monitor, the underlying glfw implementation will show the window on the corresponding screen/monitor.

Supported Improvements

This PR assumes the user has resolve the coordinate using any means. It will be more convenient if there is a method off the app package which exposes all monitors from the underlying the glfw package. So that the user can pick the coordinate without iinstalling other 3rd-party packages.

Fixes #2809 (comment)

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

Where applicable:

• Public APIs match existing style and have Since: line.
• Any breaking changes have a deprecation path or have been discussed.
• Check for binary size increases when importing new modules.

[andydotxyz]

Thanks for this, but honestly I don't think the PR implements what the title describes. It has no concept of monitors and instead is implementing Window.SetPos or Window.Move (essentialy) which has a long discussion at #1155.

As you'll note our APIs are high level and describe intent and not the underlying detail - so "I want this to be on an external display" absolutely must be about requesting a secondary display not some X/Y position.

This PR assumes the user has resolve the coordinate using any means. It will be more convenient if there is a method off the app package which exposes all monitors from the underlying the glfw package. So that the user can pick the coordinate without iinstalling other 3rd-party packages.

The user should not have to know anything about the OS X/Y coordinates to request a secondary monitor. That would mean platform specific code to make use of this API - making it kindof hard to use. The "more convenient" comment doesn't quite get us there - I think to support multiple monitor requests we really need to talk about monitors.

I would propose an abstraction for requesting a specific monitor - such as Primary and Secondary or External. Then we may have to do the hard work and the maths internally - that's how it is ;).

[andydotxyz]

As noted in my longer comment - I don't think this is the right approach as it doesn't really implement what the title indicates.

[andydotxyz]

2.7 has already been released - 2.8 is next

[andydotxyz]

My understanding is that "center on screen" and "show on external monitor" (this PR) conflict. We need to be describing monitors not x/y so that one does not override another.

[ndianabasi]

This commit addresses this concern. Request for "Center on screencallswindow.getMonitorForWindow. If w.xposandw.ypos` and set before the request for "center on screen", the correct monitor will be resolved and the window centered on the correct monitor.

https://github.com/ndianabasi/fyne/blob/33adf8a39c5c8b71d8df4b631ad3819413034dd9/internal/driver/glfw/window_desktop.go#L282-L314

[ndianabasi]

Thank you for your review @andydotxyz. If I renamed the title of this PR to reflect that coordinates are needed, would it be accepted?

Secondly, I am interested in implementing something like window.showInMonitor(monitor) and fyne.getMonitors for getting all monitors (in another PR). Would you like to initiate an issue and give me top-level requirements based on your vast experience with fyne so that I can follow and implement?

PS: I started experimenting with fyne just yesterday and discovered the limitation which necessitated this PR. I started with implementing fyne snippets which are snippets of advance usages/examples for fyne. I will shared them later.

I love the framework and will love to invest in its improvements. Cheers!

[andydotxyz]

Maybe the title change didn't take? It
Still seems to be about monitors.

If you want this to be about setting position then please read the linked issue - you will see all of the complexity.

I am much more keen to support display requesting than the potentially-problematic position setting. Particularly because the use-case you describe is related to monitor and not positions. Let's expose the API based on use-case.