Updating tk +quartz failed on Snow Leopard

Mojca Miklavec mojca at macports.org
Thu Aug 25 03:44:10 PDT 2016


Hi,

I'm moving the discussion from the user mailing list to the developer
one, hoping to catch attention of more experienced developers there.

To summarize.

Tk fails to compile on Snow Lepard due to the following chunk of code:

    MacDrawable *macDraw = (MacDrawable *) d;
    NSWindow *win = TkMacOSXDrawableWindow(d);
    int scalefactor = 1;
    if (win && [win respondsToSelector:@selector(backingScaleFactor)]) {
        scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;
    }

The function backingScaleFactor has only been added in 10.7 and
returns a floating point number.

On 10.6 the "if" sentence is false, so the "scalefactor = ..." never
gets executed. The problem is that 10.6 believes that [win
backingScaleFactor] returns "id" rather than a floating point number
(it doesn't know the function after all) and throws a compile error
because id cannot be compared with a floating point (2.0).

I found a potential workaround at
    http://stackoverflow.com/questions/307128/how-do-i-cast-id-to-a-float

and tried to replace
    scalefactor = ([[win backingScaleFactor] floatValue] == 2.0) ? 2 : 1;
with
    scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;

This avoids the build error on 10.6, but apparently doesn't compile on
10.11 at all.

> .../tk/unix/../macosx/tkMacOSXXStubs.c:901:18: error:
>       bad receiver type 'CGFloat' (aka 'double')

This is easy to patch in MacPorts only. We just remove that code when
compiling on 10.6 or earlier and we are done (we can already do that
straight away).

But it would be nice to have a proper patch for upstream.

An easy workaround would be to simply use something like
    #if __MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
rather than testing for "respondsToSelector", but if I understand
correctly that would have a slight drawback than an application
compiled on 10.6 would not be able to work as nicely on a Retina
display. I'm not an ObjectiveC speaker myself, but I remember Jeremy
H. mentioning that several times.

Then again, given that it currently doesn't compile on 10.6 at all,
there's probably not much need for that kind of functionality (=
compile on 10.6 & get a perfect app with all the latest features on
10.11) anyway. MacPorts wouldn't care because we only ever compile for
the same platform.

If anyone has any clue about how to fix the upstream source code to
make it work on both 10.6 as well as the latest OS, I would be
grateful for any hints.

Thank you,
    Mojca


More information about the macports-dev mailing list