Today’s work session started with a very simple question: How to set the position of the window properly.
I left the last log wondering how to manage the windows, but my main concern today is actually seeing how to position the windows properly on startup.
It’s a very small thing, but that’s the sort of thing I care about. I believe that our company must shine in the care for small details, in the bits that leave you like “they didn’t have to do that, but they did nonetheless”.
Also, I’m still getting used to the program, so picking these sort of smaller “surely this has an immediate solution” issues are a great way to get used to the minutiae.
For now the resource tree looks like this. Node2D is the default starting point, and then second_screen is the hypothetical second screen of the game.
This approach has one key issue: The goal is to have the second window be a pop up menu in a single-window situation. Long story short, second_screen should be instantiated (called from code) as opposed to being there in the menu, but we’ll get to that later.
For now let’s try and set the position, and we run into an interesting issue off the bat.
For the sake of testing, Godot will start the program at the center of the screen in debug mode. This is fine, but it means that me right now testing screen and window position don’t get a good sample of how that would look.
Well, not a big deal, just gotta export it.
Oh, you can have presets even repeated per platform, that’s really fucking nice, actually.
Anyway…
Exporting as-is resulted in something I couldn’t execute. Turns out Godot keeps the export files out by defaults to keep the download small which certainly explains a lot.
In fact, as I was going through it I saw the documentation literally say: “At that time, the user is expected to come back to the documentation and follow instructions on how to properly set up that platform.”
Sidenote, last time I tried to get development going before Life Happened Yet Again, I remember the documentation explained technical details about animation beyond just the code used. It reminds me of how old device manuals would teach you basics that went beyond the operation.
All in all the export templates are in the downloads section of the engine’s homepage and it’s curious how I don’t even feel inconvenienced, it’s like the engine is going “if you’re making things this should be the bare minimum you should be able to handle”.
Also, you can download them from within the software but it wasn’t working for me for some reason…
The templates turn out to be about 1.2GB so… yeah, good call to keep them out until the need to export a project comes around.
One .exe export later and I can confirm that it mirrors how it looks on the editor.
By the way, it doesn’t show its bar because it’s apparently calculating the screen size offset by the taskbar.
With that done, we can move onto the nest step of testing:
This is a script on second_screen. What I want to know if how it will move that window, so for now I’m setting it to mirror the main window’s position. I also changed the position of the window in the settings so the game starts at the center of the main monitor.
Uh…
Okay so it did spawn on the main screen. But second_screen spawned in the position it would be if-…
Ah…
second_screen is a child of Node2D, and as I found out last time, the untethered windows spawn relative to the display, as if the whole resolution of the monitor (plus the taskbar offset) was the “canvas” it worked with.
What I need is to have it retrieve the position of the application window, not of its parent node.
DisplayServer basically calls forth all the application display-related stuff. So IN THEORY second_screen should spawn on top of the application window.
Just gotta tick its “always on top” flag, and…
Perfect.
So now that we know how to grab the size of the application itself, we can probably retrieve the window’s dimensions too.
In theory, this code retrieves the vertical size of the window and spawns second_screen at “the app’s vertical position plus its vertical height”.
Hell yes.
Just an adjustment: Note how the bar overlaps, that’s because there’s apparently a different command that takes into consideration size plus bar for the dimensions since the bars might be different sizes in different OS’ and whatnot.
I’ll stop this for now.
So let’s first recap last session’s goals:
Objectives of last session:
Think of which approach I wanna take for the management of the multiple windows.- This is solved. Due to the lack of certainty on the manipulation of windows I wanted to keep open the possibility of weird shenanigans where there’s two windows and an invisible main window (deranged as it sounds). However, with the solutions applied I can take a more normal approach where second_screen houses its own things.
And when I do, decide on dimensions where the “second screen” can be slotted inside the main one so as to futureproof the UI upon the inevitability of single-screen devices.- This is incomplete, but I’ve reworded it for next session.
With that in mind…
Objectives for next session:
- Investigate how to change the embedded window option upon startup
- Part of the soft futureproofing research. Making the second-screen UI something that slides in would be perfect for single-screen setups, but might not be possible with untethered windows. I need to see if there’s an option for a window to be tethered regardless of project settings, or make the UI in such a way that it can spawn off a window or any other setup as needed.
- Decide on a preliminary choice of resolution, and adjust the spawning points so they’re better aligned
- For simple aesthetic purposes it should spawn horizontally at the middle point of the main screen and vertically with the bar accounted for.
- Prototype the UI position as it would be on a single-screen option
- I should sketch the rough UI idea, actually. That way I can choose resolutions accordingly.
- Instantiate second_screen.
- As mentioned, minor futureproofing. It should be spawned via code rather than being part of what I see in the editor.