~eliasnaur/gio#19:
Add multiple top-level windows

Right now Gio creates a top-level window for you and that's the only one you get to interact with. That makes total sense for phones or webpages, but not the desktop. So supporting multiple top-levels would be nice. (Bonus points / extra credit for somehow supporting that transparently in the browser! :)

I suppose one could just fork a new process per top-level window, and then they could communicate via local RPC, but I think that would be sub-optimal, if there's any way around it.

Status
REPORTED
Submitter
~theclapp
Assigned to
No-one
Submitted
2 months ago
Updated
a month ago
Labels
No labels applied.

~dennwc a month ago

Another questions to consider: how the app will know if it's running in a multi-window OS or not? We can probably expose some global function that app can call to know this, but I'm not sure this information is always available before creating a window (e.g. checking extensions support, etc). So maybe return an ErrOnlyOneWindow from app.NewWindow?

Also, should we allow a rendering goroutine per window? It sounds reasonable, especially for a future (Vulkan), but needs to be considered carefully when designing internals.

~eliasnaur a month ago

On Thu Aug 29, 2019 at 9:17 PM ~dennwc wrote:

Another questions to consider: how the app will know if it's running in a multi-window OS or not? We can probably expose some global function that app can call to know this, but I'm not sure this information is always available before creating a window (e.g. checking extensions support, etc). So maybe return an ErrOnlyOneWindow from app.NewWindow?

I expect a multi-window program to either not support single window systems or check runtime.GOOS or similar before proceeding. I think it's harder to image a program that changes its behaviour according to the result of the second NewWindow call.

Also, should we allow a rendering goroutine per window? It sounds reasonable, especially for a future (Vulkan), but needs to be considered carefully when designing internals.

What do you mean by rendering goroutine? If you mean the program controlled goroutine that fetches events from Window.Events, then I hope it will be up to the program to decide. It could run the windows from different goroutines or it could select on multiple window's Event channel from a single goroutine.

-- elias

~dennwc a month ago

On Thu, 29 Aug 2019 at 21:29, ~eliasnaur outgoing@sr.ht wrote:

On Thu Aug 29, 2019 at 9:17 PM ~dennwc wrote:

Another questions to consider: how the app will know if it's running in a multi-window OS or not? We can probably expose some global function that app can call to know this, but I'm not sure this information is always available before creating a window (e.g. checking extensions

support, etc). So maybe return an ErrOnlyOneWindow from

app.NewWindow?

I expect a multi-window program to either not support single window systems or check runtime.GOOS or similar before proceeding. I think it's harder to image a program that changes its behaviour according to the result of the second NewWindow call.

I can imagine some kind of visual/sound editing app with a main window and small tool windows. It could fallback to rendering those tool windows inside the main one or draw a few on-screen buttons if it's an app for Android, for example.

But you are right, it's probably easier to work with a single mode, e.g. a single window if the goal is to support such diverse platforms. All make two binaries with slightly different root layouts.

Also, should we allow a rendering goroutine per window? It sounds reasonable, especially for a future (Vulkan), but needs to be considered carefully when designing internals.

What do you mean by rendering goroutine? If you mean the program controlled goroutine that fetches events from Window.Events, then I hope it will be up to the program to decide. It could run the windows from different goroutines or it could select on multiple window's Event channel from a single goroutine.

Yeah, sorry, forgot the immediate mode specifics. I meant the routine that processes events for each window.

To be honest, I haven't looked too deep into multi-window support and how it works from the users perceptive, hence the misunderstanding from my side. X11 backend that I've worked supports only a single window for now.

-- elias

View on the web: https://todo.sr.ht/~eliasnaur/gio/19#comment-3537

Best regards, Denys Smirnov.

~dennwc referenced this from #19 a month ago

~eliasnaur a month ago

To be honest, I haven't looked too deep into multi-window support and how it works from the users perceptive, hence the misunderstanding from my side. X11 backend that I've worked supports only a single window for now.

The other backends also only support one window for now :)

~dennwc a month ago

The other backends also only support one window for now :)

That explains a few things in the code :D

~theclapp referenced this from #33 a month ago

~eliasnaur referenced this from #33 a month ago

Register here or Log in to comment, or comment via email.