premake/README-ios.txt
author Sam Lantinga <slouken@libsdl.org>
Sun, 17 Aug 2014 14:57:52 -0700
changeset 9086 c5e33f9a0d03
parent 8921 4a9feef61c85
child 9876 1496e502e51d
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.
icculus@7925
     1
Use the Xcode command files (located in the Xcode-iOS/build-scripts folder)
icculus@7925
     2
to conveniently generate a workspace for Xcode 3 or Xcode 4. It also
icculus@7925
     3
contains a cleaner script and a convenient script for automatically
icculus@7925
     4
running all the test suites.
icculus@7925
     5
icculus@7925
     6
The iOS project will be referencing all files related to the top-level iOS
icculus@7925
     7
project. The core library will use the top-level include and src directories,
icculus@7925
     8
just like the other generated projects, but it will build projects for each of
icculus@7925
     9
the Demos in the top-level Xcode-iOS folder. These projects will have any
icculus@7925
    10
resources they need copied to be copied over and included as resources. They
icculus@7925
    11
will also reference the Info.plist file in Xcode-iOS/Demos.
icculus@7925
    12
icculus@7925
    13
iOS support is currently experimental, but it should work just fine for any and
icculus@7925
    14
all applications. All of the demos that work from the manually-created Xcode
icculus@7925
    15
projects also work for the generated projects. There are a few minor things that
icculus@7925
    16
need improving, but nothing major.
icculus@7925
    17
icculus@7925
    18
The iOS projects have no major dependencies other than the ones in the manual
icculus@7925
    19
Xcode-iOS project. Those are:
icculus@7925
    20
icculus@7925
    21
  -AudioToolbox.framework
icculus@7925
    22
  -QuartzCore.framework
icculus@7925
    23
  -OpenGLES.framework
icculus@7925
    24
  -CoreGraphics.framework
icculus@7925
    25
  -UIKit.framework
icculus@7925
    26
  -Foundation.framework
icculus@7925
    27
  -CoreAudio.framework
slouken@8921
    28
  -CoreMotion.framework
icculus@7925
    29
icculus@7925
    30
All of these frameworks are part of the iOS SDK, not part of the core OS X
icculus@7925
    31
system.
icculus@7925
    32
icculus@7925
    33
Run the clean script to clear out the directory of Xcode-related files
slouken@8921
    34
and binaries.