premake/README-linux.txt
author Sam Lantinga <slouken@libsdl.org>
Sun, 17 Aug 2014 14:57:52 -0700
changeset 9086 c5e33f9a0d03
parent 7925 f090a47eb7f7
permissions -rwxr-xr-x
Fixed bug 2655 - OSX: Window position and global mouse coord spaces are different

Tim McDaniel

On OSX, with revision 8729, the coordinate space for window position and the coordinate space for global mouse position don't match. For a non-fullscreen window, the window position is global relative to the bottom of the menubar. The global mouse position is relative to the top of the screen. This affects Cocoa_WarpMouse and potentially other things as well. Further, the coordinate system for window position is now affected by what screen it is on. For example, if I have two equal size screens oriented side by side such that the tops of the screens are equal in global space, with the menubar on one screen, and a window straddles the two screens, the window's y position makes no sense. The window's y position depends on what screen "most" of the window is on. So if I move the window horizontally just a bit, the y position of my window is now different by the size of the menubar, even though the window was not moved vertically.

I'd like to reiterate that this was a fairly fundamental change (and a breaking change for us). If SDL OSX is to really support multi-display configurations, this is especially problematic.

If the real concern is preventing windows from going under the menubar, then perhaps a solution involving something like overriding [NSWindow constrainFrameRect] would be less problematic than redefining the global window coord space for the main display.
     1 You may generate GNU makefiles for building SDL2 and its related test suite by
     2 using the gmake shell script in the Linux/build-scripts folder.
     3 
     4 Linux support is currently experimental for the meta-build system. Most of the
     5 progress made on this support happened toward the end of the meta-build system
     6 project, so there is a lot currently missing that could be added in the future.
     7 For the most part, the Linux support works well, but there is a significant
     8 amount of testing needed to verify it can be built in many different
     9 environments.
    10 
    11 The Linux project does not target every dependency it should (as seen in the
    12 autotools configure script or in the CMake script), but it does target the
    13 following dependencies:
    14 
    15   -D-Bus (required to build Linux at all)
    16   -DLOpen (most of the other dependencies are dependent on this)
    17   -ALSA
    18   -PulseAudio
    19   -ESD
    20   -NAS
    21   -OSS
    22   -X11
    23   -OpenGL
    24 
    25 Also, the Linux system should be building the SDL2 library as a shared library,
    26 but it builds it as a static library because of a few premake-related issues.
    27 This is because when the makefile generated by premake tells the linker where to
    28 find the definitions library (libSDL2.o), it also gives a hint to the loader to
    29 find libSDL2.so in the same place, with a relative path. This means in order to
    30 execute the program dynamically linked to SDL2, it's looking in some path like:
    31 
    32   "../../SDL2/Build/Debug"
    33 
    34 Now, while this path works at the location of the makefile (such as
    35 ./tests/testsprite), it does not make sense from the actual location of the
    36 executable (./tests/testsprite/Build/Debug). Furthermore, it's just massively
    37 inconvenient to have a relative path to look for the shared object. Moving
    38 libSDL2.so into the same directory as the executable does not solve this issue.
    39 Unfortunately, premake also does not allow an install target to be created for
    40 the makefiles, which is another one of the major issues related to building SDL2
    41 as a shared library on Linux. Once these problems are solved, this support
    42 should be very straightforward to add to this system in the future.
    43 
    44 The Linux system does have both an automated test and cleaning shell files for
    45 running through the entire supported test suite and cleaning up the generated
    46 and built files, respectively.