[Adium-devl] AIApplicationAdditions changes in [20513] / [20515] / [20517]

[Elliott Harris]

Point.

The Gestalt code was added in r20491 to remove poseAsClass from  
Leopard, which is what prompted the change to handle specific  
versions, although it was a bit of overkill. It's all fixed up in   
r20534, and the end result is that we have enough of an API that  
keeping track of Tiger-only code will be easy, we don't have to write  
Gestalt every time we need to separate out some specific Tiger code,  
and we can use LeopardOrBetter for Leopard specific code.

-Elliott
On Aug 11, 2007, at 11:45 AM, Evan Schoenberg wrote:

>
> On Aug 10, 2007, at 7:10 PM, Elliott Harris wrote:
>
>> On Aug 10, 2007, at 5:31 PM, Evan Schoenberg wrote:
>>
>>> 1.
>>> What are these changes for?  We've gone from single mathematical  
>>> operation (a constant compared to a constant) to loading a file  
>>> from disk, parsing it to a dictionary, extracting a string from   
>>> the dictionary, creating an array out of it, then comparing  
>>> values from that array.
>>>
>> The changes are designed to move us away from using the AppKit  
>> version number for checking OS version. This accomplishes two  
>> things. First, it lets us test for a particular version number or  
>> a particular OS version without using Gestalt.
>
> We weren't using Gestalt.  For easy reference the old code for  
> checking for Tiger, for example, was:
> - (BOOL)isOnTigerOrBetter
> {
>         return (floor(NSAppKitVersionNumber) >  
> NSAppKitVersionNumber10_3);
> }
>
> Both NSAppKitVersionNumber and NSAppKitVersionNumber10_3 are simple  
> constants.
>
>> Second, it lets us do this without depending on version numbers  
>> which might be NDA'd. The goal is to be able to recognize Leopard  
>> in certain situations, so that we can handle things more easily.  
>> It's a bit more costly, but gives us more control.
>
> Version numbers which might be NDA'd?  The AppKit version number is  
> needed for the most recent released version, not for a later one.   
> For example, to check if we are running on 10.5 or later, we simply do
> - (BOOL)isOnLeopardOrBetter
> {
>         return (floor(NSAppKitVersionNumber) >  
> NSAppKitVersionNumber10_4);
> }
>
> If both 10.5 and 10.6 existed simultaneously as NDA'd systems, we  
> would not be able to differentiate them, true.  I really doubt that  
> situation will come up...
>
>> Obviously, point release checking is a bit of overkill, but it's a  
>> lot nicer than having to string up Gestalt code everytime you need  
>> to check the OS version.
> Again, no Gestalt code has been used in the old implementation...
>
>> Moving forward, I suspect that a fair amount of code will be split  
>> between Tiger and Leopard versions for the sake of taking  
>> advantage of some of the new excellent Leopard APIs. However,  
>> since we have no planned version to go 10.5 only, a good API for  
>> testing these changes and completely distinguishing between the  
>> two versions, and not just checking for whether we are better than  
>> a certain version seemed necessary.
>
> isTiger could be implemented as (floor(NSAppKitVersionNumber) ==  
> NSAppKitVersionNumber10_4).  It's true that isLeopard, until  
> Leopard is actually released, can't be definitively implemented if  
> you accept the idea that the app kit version number is NDA'd -  
> which technically it probably is.  Still, the knowledge that 10.6  
> Liger doesn't exist yet means that isLeopard implemented as return  
> [self isOnLeopardOrBetter] is really quite acceptable, especially  
> since the OS being NDA'd is a temporary situation which will be  
> resolved in 2 months.
>
>> It may be hard to see the use now, but I feel that having a solid  
>> and thorough API for version checking can make working between two  
>> OS versions a lot easier.
>
> Good code snippet to put on your coding blog or something? For  
> sure; it's a nice, elegant way to do version checking at point  
> release granularity. Necessary for our purposes? The only thing I  
> can see coming up is if the new WebKit gets rolled into a 10.4  
> update, at which point we might want to handle that version (or  
> later) specifically.
>
> -Evan
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070811/691d466b/attachment-0001.html>