Support multiple windows on desktop platforms only #532

New issue

Open

opened 2022-09-14 19:44:44 +00:00 by emidoots · 4 comments

emidoots commented

2022-09-14 19:44:44 +00:00

(Migrated from github.com)

I'd like to support multiple windows on desktop platforms (e.g. for the editor to have breakout windows that dock/undock if you drag'n'drop a window onto the main one.)

Of course, multiple windows will not work on most other platforms (at least mobile, consoles, etc.) - WASM would be nice-to-have.

I'd like to support multiple windows on desktop platforms (e.g. for the editor to have breakout windows that dock/undock if you drag'n'drop a window onto the main one.) Of course, multiple windows will not work on most other platforms (at least mobile, consoles, etc.) - WASM would be nice-to-have.

emidoots commented

2022-09-14 20:26:10 +00:00

(Migrated from github.com)

Here's a starting point perhaps?

Add Core.createWindow, it returns a new *Window type (which I imagine would largely have identical fields to Core today.)
Add Window.setOptions, Window.setShouldClose, Window.getFramebufferSize, Window.getSize, Window.close

Then inside your app's pub fn init or pub fn update you could call this API to create a new window and render to it.

Here's a starting point perhaps? * Add `Core.createWindow`, it returns a new `*Window` type (which I imagine would largely have identical fields to `Core` today.) * Add `Window.setOptions`, `Window.setShouldClose`, `Window.getFramebufferSize`, `Window.getSize`, `Window.close` Then inside your app's `pub fn init` or `pub fn update` you could call this API to create a new window and render to it.

kchilton commented

2024-09-19 22:20:16 +00:00

(Migrated from github.com)

I am very interested in seeing this feature happen. I looked over what it could take to do it and has some questions to refine what you had in mind.

Why differentiate the main_window from other windows? Why not have all windows, whether a pop-up or undock or other hierarchical relationship, or just two windows under the same app treated all the same way? All window creation would return an EntityID.
Do not Windows need to know which entities are contained within? The database needs to record which window the entities are in and when a window is destroyed, the entities need to be destroyed or moved to another window (such as redocking the undocked window).
Is there a relationship or dependency to control on windows? Or let the user choose to destroy child windows by callback from the destruction of the parent?

Thoughts?

I am very interested in seeing this feature happen. I looked over what it could take to do it and has some questions to refine what you had in mind. 1. Why differentiate the main_window from other windows? Why not have all windows, whether a pop-up or undock or other hierarchical relationship, or just two windows under the same app treated all the same way? All window creation would return an EntityID. 2. Do not Windows need to know which entities are contained within? The database needs to record which window the entities are in and when a window is destroyed, the entities need to be destroyed or moved to another window (such as redocking the undocked window). 3. Is there a relationship or dependency to control on windows? Or let the user choose to destroy child windows by callback from the destruction of the parent? Thoughts?

emidoots commented

2024-09-19 22:43:06 +00:00

(Migrated from github.com)

Hey @kchilton - there is a major API design change of the Core.zig API currently underway, and also our ECS. It's been discussed briefly in the Discord #contributing channel, and I'll have a PR up for it in the next few weeks probably.

After that change we'll be able to support this easily I think.

Hey @kchilton - there is a *major* API design change of the `Core.zig` API currently underway, and also our ECS. It's been discussed briefly in the Discord #contributing channel, and I'll have a PR up for it in the next few weeks probably. After that change we'll be able to support this easily I think.

kchilton commented

2024-09-20 15:49:18 +00:00

(Migrated from github.com)

I envisioned a framework registry that could even handle context-selected composition roots, which should make the scenarios above (undocking, popups, ...) intuitive. Of course, such a more complicated framework could be layered on top of Mach, which is what I was working on for the simple purpose of assembling a GUI and modeling framework to support my future projects when I stumbled on this Issue. I look forward to seeing the new ECS design!

Thanks for responding. I looked over the Discord and the subthread "thinking on new ECS thingy". I would have loved hearing more of the discussion related to inversion of control, how ECS affects the interfaces, and how to handle parallelism. It looks like I could have learned a lot from that exploration. I envisioned a framework registry that could even handle context-selected composition roots, which should make the scenarios above (undocking, popups, ...) intuitive. Of course, such a more complicated framework could be layered on top of Mach, which is what I was working on for the simple purpose of assembling a GUI and modeling framework to support my future projects when I stumbled on this Issue. I look forward to seeing the new ECS design!