Opened 13 years ago

Closed 10 years ago

#907 closed defect (fixed)

[PATCH] Wrong window position on Windows with taskbar on top

Reported by: vts Owned by:
Priority: If Time Permits Milestone: Alpha 17
Component: Core engine Keywords: patch windows
Cc: Patch:

Description

On Windows, if the taskbar is at the top of the screen, windows spawned at (0,0) will slide under the taskbar and hide the min/max/X controls. This small patch first queries for the usable desktop area and spawns the window relative to that instead.

Attachments (1)

wsdl_window_pos_patch.patch (951 bytes ) - added by vts 13 years ago.

Download all attachments as: .zip

Change History (11)

by vts, 13 years ago

Attachment: wsdl_window_pos_patch.patch added

comment:1 by historic_bruno, 13 years ago

Milestone: BacklogAlpha 7

comment:2 by Kieran P, 13 years ago

Keywords: simple patch added

comment:3 by Philip Taylor, 13 years ago

Keywords: simple review removed

This doesn't seem to work properly in fullscreen mode - when I test on Vista with the taskbar at the top of the screen, the taskbar remains visible (above the fullscreen game area) and the bottom of the game falls off the bottom of the screen and isn't visible. I guess this should only be applied in non-fullscreen mode.

comment:4 by Kieran P, 13 years ago

Milestone: Alpha 7Alpha 8

comment:5 by vts, 13 years ago

My bad -- my earlier patch indeed doesn't take fullscreen mode into account. There have been some talks about moving away from WSDL to regular SDL which might deal with this automatically, so I'm currently unsure whether to go ahead and fix it or leave it and wait for the move to regular SDL.

in reply to:  5 ; comment:6 by historic_bruno, 12 years ago

Milestone: Alpha 8Backlog

Replying to vts:

My bad -- my earlier patch indeed doesn't take fullscreen mode into account. There have been some talks about moving away from WSDL to regular SDL which might deal with this automatically, so I'm currently unsure whether to go ahead and fix it or leave it and wait for the move to regular SDL.

I tested switching from wsdl to official SDL 1.2, and there are bugs to work around, the most serious is #741 (affects both Windows and OS X). It seems unlikely we will be switching from wsdl in the near future, certainly not before that bug is fixed.

comment:7 by Markus, 11 years ago

Keywords: windows added

in reply to:  6 comment:8 by historic_bruno, 11 years ago

Replying to historic_bruno:

I tested switching from wsdl to official SDL 1.2, and there are bugs to work around, the most serious is #741 (affects both Windows and OS X). It seems unlikely we will be switching from wsdl in the near future, certainly not before that bug is fixed.

These have been fixed in SDL 2.0 (see progress at #935), and I will test this issue as well.

comment:9 by historic_bruno, 11 years ago

Hmm no, the positioning under the taskbar bug still occurs in SDL 2.0, actually it's even worse because it places the window off screen if 0,0 is used for the window coordinates. They don't consider this a bug, rather a missing API. However, it can be covered up by using SDL_WINDOWPOS_* macros (we should use these anyway with SDL 2.0, because they offer multidisplay support).

Last edited 11 years ago by historic_bruno (previous) (diff)

in reply to:  9 comment:10 by historic_bruno, 10 years ago

Milestone: BacklogAlpha 17
Resolution: fixed
Status: newclosed

Replying to historic_bruno:

However, it can be covered up by using SDL_WINDOWPOS_* macros (we should use these anyway with SDL 2.0, because they offer multidisplay support).

This is what we do, and SDL2 is now the default on Windows as of r15786, so I'm resolving this as "fixed".

Note: See TracTickets for help on using tickets.