Inertia's picture

GameWindowFlags

Project:The Open Toolkit library
Version:0.9.9-1
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed
Description

The enum OpenTK.GameWindowFlags only got a parameter for fullscreen, none for windowed display (you can cast (GameWindowFlags)0 to achieve it though).

Request: Add at least 1 more option to the enum, since it is required when using the longer constructors (e.g. to use a specific GL version). Even if the final build of the application will use the fullscreen flag, it is usually better to develop with a window.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#1

Status:open» confirmed

I've been meaning to do this for months, but keep forgetting. Thanks for the reminder!

the Fiddler's picture

#2

Version:0.9.9-0» 0.9.x-dev
Status:confirmed» fixed

Fixed in rev. 1990.

Inertia's picture

#3

Thanks for the fix :)

What I meant with "at least 1 more option" was that it might make sense to add a third option: GameWindowFlag.Minimized.

A friend experienced problems using a fullscreen GameWindow app together with Comodo firewall (the application has no network logic, but the firewall seemed not happy with OpenTK.Input). Since the app was fullscreen he could not respond to the firewalls input window and neither alt+tab nor ctrl+alt+del did work (he had to reboot and manually add the app to firewall exception before he could run it).

Idk whether this is worth investigating further (you might aswell start the app "windowed" first), but I thought it should be mentioned.

the Fiddler's picture

#4

Well, debugging fullscreen applications is certainly a pain, unless you have a second monitor. I tend to place an #if DEBUG section that makes the app windowed to avoid exactly this issue.

I cannot really see what a firewall has to say about OpenTK.Input. It must be somehow detecting that WMInput.cs is subclassing WinGLNative.cs to steal its input messages, but I don't think a firewall is supposed to do that at all! This is a typical pattern and it's done inside a single process anyway - it's not as if a rogue application is trying to hook another.

OpenTK.Input is undergoing significant changes right now (additions, not modifications) that could sort this out. I'd suggest opening a bug report so it doesn't get lost, however.

Inertia's picture

#5

I'll first investigate whether that behaviour is only related to OpenTK or other applications aswell, before filing an issue. I'm also not sure whether he has installed the full "Internet Security Suite" or just the firewall, his report was more like cursing his firewall for making him restart the computer, then we moved on to issues related to the actual application I asked him to run.

the Fiddler's picture

#6

Status:fixed» closed

Closing bugs fixed in 0.9.8-2 and 0.9.9-1.

the Fiddler's picture

#7

Version:0.9.x-dev» 0.9.9-1