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

Evan Schoenberg evan.s at dreskin.net
Sat Aug 11 16:45:36 UTC 2007


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070811/4f7d2657/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070811/4f7d2657/attachment.sig>


More information about the devel mailing list