Resizable borderless windows in Lion

  • Hi List.

    In Unity, we have custom titlebars for our windows and I'm trying to make them work nicely in Lion.

    Reading the Lion release notes, it says I should create my window with NSBorderlessWindowMask | NSResizableWindowMask. It also says that my app needs to be compiled with Lion as a backwards-compatibility measure. Here comes my problem:

    Our build farm uses Snow Leopard Server (latest version), and GCC 4.2.1. Is there any way for me to let get around the "must be compiled on Lion" check?

    Sorry if this question has been answered already. I tried the search on lists.apple.com but got an error from the search engine. Google came up blank.

    TIA,
    Nicholas Francis
  • On Nov 17, 2011, at 2:33 AM, Nicholas Francis wrote:

    > Reading the Lion release notes, it says I should create my window with NSBorderlessWindowMask | NSResizableWindowMask. It also says that my app needs to be compiled with Lion as a backwards-compatibility measure.

    I’m pretty sure that just means that it needs to be compiled with the Lion *SDK*, i.e. by Xcode 4.2. That’s available for 10.6.

    —Jens
  • On 17 Nov 2011, at 17:36, Jens Alfke wrote:

    >
    > On Nov 17, 2011, at 2:33 AM, Nicholas Francis wrote:
    >
    >> Reading the Lion release notes, it says I should create my window with NSBorderlessWindowMask | NSResizableWindowMask. It also says that my app needs to be compiled with Lion as a backwards-compatibility measure.
    >
    > I’m pretty sure that just means that it needs to be compiled with the Lion *SDK*, i.e. by Xcode 4.2. That’s available for 10.6.

    Seriously? SDKs are never usually backported. Would be great if they were somehow.
  • On Nov 17, 2011, at 10:48 AM, Mike Abdullah wrote:

    >>> Reading the Lion release notes, it says I should create my window with NSBorderlessWindowMask | NSResizableWindowMask. It also says that my app needs to be compiled with Lion as a backwards-compatibility measure.
    >>
    >> I’m pretty sure that just means that it needs to be compiled with the Lion *SDK*, i.e. by Xcode 4.2. That’s available for 10.6.
    >
    > Seriously? SDKs are never usually backported. Would be great if they were somehow.

    I did some testing last week. Building with the 10.7 SDK with 4.2 on SL vs Lion, I ended up with byte-identical binaries. The only thing that was different were the compiled nibs, and I think one other thing. Not sure exactly what the differences were though, but they varied quite a bit. I didn't compare the 10.7-SDK-built-on-SL nibs to 10.6-SDK-built-on-SL nibs to see if they were the same.

    --
    Seth Willits
  • Problem with Xcode >4 is that this is the same build farm that compiles out standalone executable which has compatibility down to Tiger, so we're stuck on Xcode 3.x versions (at least for the next 8 months or so). Superannoying, but that's what we get for making a dev tool that will target ancient systems.

    Essentially, Unity is an Editor (that requires >Leopard, Intel only) which we ship with a bunch of runtimes (OSX, iOS, Win, Android (ARM/Intel, etc), PS3, XBox, Flash binary, etc.). People use the Unity editor to build a data file that these binaries know how to run. The Editor could be compiled with a later compiler, but we need our runtimes to target ancient systems as well (when to up the requirements of any version is a long debate; we're just now dropping PPC). The editor also has an embedded Runtime (so people can test their games).

    However, getting all these dependencies right means we've ended up with a very complex build system - so it's hard for us to "just" upgrade a single piece of the chain.

    Anyone have any idea how Lion checks the compiler version so I maybe can fool it?

    (Failing that, I'll re-implement windows resizing myself :)

    Thanks,
    Nicholas

    On Nov 17, 2011, at 8:04 PM, Seth Willits wrote:

    > On Nov 17, 2011, at 10:48 AM, Mike Abdullah wrote:
    >
    >>>> Reading the Lion release notes, it says I should create my window with NSBorderlessWindowMask | NSResizableWindowMask. It also says that my app needs to be compiled with Lion as a backwards-compatibility measure.
    >>>
    >>> I’m pretty sure that just means that it needs to be compiled with the Lion *SDK*, i.e. by Xcode 4.2. That’s available for 10.6.
    >>
    >> Seriously? SDKs are never usually backported. Would be great if they were somehow.
    >
    >
    > I did some testing last week. Building with the 10.7 SDK with 4.2 on SL vs Lion, I ended up with byte-identical binaries. The only thing that was different were the compiled nibs, and I think one other thing. Not sure exactly what the differences were though, but they varied quite a bit. I didn't compare the 10.7-SDK-built-on-SL nibs to 10.6-SDK-built-on-SL nibs to see if they were the same.
    >
    >
    > --
    > Seth Willits
  • Le 18 nov. 2011 à 10:59, Nicholas Francis a écrit :

    > Problem with Xcode >4 is that this is the same build farm that compiles out standalone executable which has compatibility down to Tiger, so we're stuck on Xcode 3.x versions (at least for the next 8 months or so). Superannoying, but that's what we get for making a dev tool that will target ancient systems.
    >
    > Essentially, Unity is an Editor (that requires >Leopard, Intel only) which we ship with a bunch of runtimes (OSX, iOS, Win, Android (ARM/Intel, etc), PS3, XBox, Flash binary, etc.). People use the Unity editor to build a data file that these binaries know how to run. The Editor could be compiled with a later compiler, but we need our runtimes to target ancient systems as well (when to up the requirements of any version is a long debate; we're just now dropping PPC). The editor also has an embedded Runtime (so people can test their games).
    >
    > However, getting all these dependencies right means we've ended up with a very complex build system - so it's hard for us to "just" upgrade a single piece of the chain.
    >
    > Anyone have any idea how Lion checks the compiler version so I maybe can fool it?
    >

    http://www.mulle-kybernetik.com/weblog/2009/04/_nsi3_cfexecutablelinkedonor
    af.html


    > (Failing that, I'll re-implement windows resizing myself :)
    >
    > Thanks,
    > Nicholas

    -- Jean-Daniel
  • Le 18 nov. 2011 à 11:59, Jean-Daniel Dupas a écrit :

    >
    > Le 18 nov. 2011 à 10:59, Nicholas Francis a écrit :
    >
    >> Problem with Xcode >4 is that this is the same build farm that compiles out standalone executable which has compatibility down to Tiger, so we're stuck on Xcode 3.x versions (at least for the next 8 months or so). Superannoying, but that's what we get for making a dev tool that will target ancient systems.
    >>
    >> Essentially, Unity is an Editor (that requires >Leopard, Intel only) which we ship with a bunch of runtimes (OSX, iOS, Win, Android (ARM/Intel, etc), PS3, XBox, Flash binary, etc.). People use the Unity editor to build a data file that these binaries know how to run. The Editor could be compiled with a later compiler, but we need our runtimes to target ancient systems as well (when to up the requirements of any version is a long debate; we're just now dropping PPC). The editor also has an embedded Runtime (so people can test their games).
    >>
    >> However, getting all these dependencies right means we've ended up with a very complex build system - so it's hard for us to "just" upgrade a single piece of the chain.
    >>
    >> Anyone have any idea how Lion checks the compiler version so I maybe can fool it?
    >>
    >
    > http://www.mulle-kybernetik.com/weblog/2009/04/_nsi3_cfexecutablelinkedonor
    af.html

    >

    As a follow up, it look like everithing end up calling NSVersionOfLinkTimeLibrary() which is defined in the following file:

    http://opensource.apple.com/source/dyld/dyld-195.5/src/dyldAPIsInLibSystem.
    cpp


    As you can see, this function has a major flaw, as it check version against the executable only.
    A tricky way to fool the system can be to move all you application code into a framework, and have a simple launcher compiled on 10.7 that just call a 'main' entry point in your framework.

    >> (Failing that, I'll re-implement windows resizing myself :)
    >>
    >> Thanks,
    >> Nicholas

    -- Jean-Daniel
previous month november 2011 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
Go to today