[PATCH] util: add Mac-specific check whether we're in a GUI session (issue2553)

Dan Villiom Podlaski Christiansen danchr at gmail.com
Wed Mar 23 05:25:24 CDT 2011


On 23 Mar 2011, at 11:00, Mads Kiilerich wrote:

> Hardcore Mac users don't use X and forwarding over ssh?

Originally, before I discovered __CF_USER_TEXT_ENCODING didn't suffice, 
[1] I had a patch with a much longer commit message which addressed  
this. I've pasted it below as it explains in full why this is an  
improvement. The short version, though, is that the previous behaviour  
was arguably wrong, and the new behaviour is easily worked around.  
Longer term, it would be nice for merge tools to be able to set 'gui'  
to either 'mac', 'windows' or 'x11', but I considered that too  
invasive for the simple patch.

>> +        elif getattr(osutil, 'isgui', None):
>> +            # check if a CoreGraphics session is available
>> +            return osutil.isgui()
>> +        else:
>> +            # pure build; use a safe default
>> +            return True
>
> (It would perhaps be a bit cleaner to put a stub in osutil.py.)

Sure, I can do that. Another approach that I considered was moving  
util.gui() into the windows/posix modules. Would that be better?

[1] It appears the CoreFoundation runtime sets the variable gets  
during setup of the Python VM, even in console sessions.

[2]
>>>
>>> util: don't use $DISPLAY to determine whether a Mac GUI is present  
>>> (issue2553)
>>>
>>> Normally, people think of a GUI application on Mac OS X as an  
>>> application that provides uses the native window server. This  
>>> specifically excludes X11 applications. Mac OS X does not provide  
>>> an officially supported environment variable similar to $DISPLAY  
>>> that indicates that an Aqua session is available, so we fake it:  
>>> $__CF_USER_TEXT_ENCODING is set by the Aqua session to indicate  
>>> the default text encoding, and is present in at least 10.4 and  
>>> onwards.[1] Local testing on Mac OS X 10.6 confirms that it's not  
>>> set when SSH-ing into localhost, when creating a new terminal  
>>> session with 'login' nor in a console session.
(this is where I got it wrong)
>>>
>>> Mac OS X 10.5 and later (that is, Leopard, Snow Leopard and Lion)  
>>> provide a way of launching an X server dynamically. This causes  
>>> $DISPLAY to be set in Aqua sessions if the (optional) X server is  
>>> installed, and explains why many users don't run into this bug.
>>>
>>> Please note that this may cause a theoretical regression for  
>>> people who actually relied on the past behaviour when SSH-ing into  
>>> a Mac to use a Mercurial configured to use an X11-based merge  
>>> tool. However, the previous behaviour was arguably a bug, and the  
>>> new behaviour can be easily worked around by setting gui=0 on Macs  
>>> for X11-based merge tools. If this turns out to be a genuine  
>>> issue, we could introduce a way of specifying which type of GUI  
>>> session a merge tool requires. However, such a change would be  
>>> much more invasive that simply fixing gui() for Mac OS X and is  
>>> beyond the scope of this patch.
>>>
>>> [1] Comments in the bug report state that it's present on 10.5  
>>> onwards. The dump included in <http://www.devdaily.com/blog/post/java/java-faq-access-read-system-properties-environment 
>>> > suggests that it's present in 10.4 as well.

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com



More information about the Mercurial-devel mailing list