Skip to content

get_available_monitors() / get_primary_monitor() ergonomics #555

@Ratysz

Description

@Ratysz

Right now, get_available_monitors() and get_primary_monitor() are methods of EventsLoop - that means knowing which monitors are connected to the system is only possible in a context where EventsLoop can be borrowed, which creates some issues when writing abstractions.

If at all possible, it would be very useful if Window also had these methods - after all, it already has get_current_monitor().

Concrete usecase (from ggez):

We have a struct, Context, that encapsulates away many of the inter-operation boilerplate of the engine, so it makes sense for it to own the Window. It cannot also own the EventsLoop, because Context needs to be available to make callbacks on based on the events within the loop.

Some of the callbacks are user-defined, and, it being a game engine and all, being able to tell the app to go fullscreen from within such a callback is desirable. Ideally, on any monitor, not just the current one, and that needs the data from get_available_monitors() and/or get_primary_monitor().

(Current workaround is to cache data from get_available_monitors() within the Context at initialization - EventsLoop is borrowed during that time, to initialize a Window.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    C - in progressImplementation is proceeding smoothlyD - easyLikely easier than most tasks hereS - apiDesign and usability

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions