Инноваций в Леопарде намного больше, чем широко озвученные "300+". Общественным достоянием стали только те из них, которые простой человек, при желании, может "пощупать" своими руками, и составить собственное суждение. Но стороннему наблюдателю видна только верхушка айсберга. На самом деле, их никак не меньше десяти тысяч.
Остальные - "не для всех". Рассказать о них не так просто. И Apple не сообщает о них именно из-за этого. И простому недоверчивому человеку "попробовать" их на вкус и ощупь, увы, почти невозможно. Рассказать о них непросто, но я попробую.
В мае (в статье Maybe I'm a Leo) я писал, что:
Разработка Леопарда совпала с тремя драматическими периодами в истории Apple. Маки перешли на процессоры от Intel, главный (единственный!) конкурент выпустил Windows Vista и Apple, Inc поставила на кон собственную судьбу и репутацию, публично заявив о намерении заново изобрести мобильный телефон. Ничего сопоставимого по значению с любым из этих событий не происходило во время разработки ни одной из предыдущих версий системы.
Я упустил из виду еще один, четвертый по счету, драматический период... и с ним - целый ворох радикальных глубинных изменений. Самую настоящую 64-битную революцию. По драматизму, этот переход едва ли не посложнее перехода на Intel.
1. Вот такая у нас эволюция!
64-битность нужна: хотя бы для того, чтобы можно было (без всяких хитрых трюков) запросто использовать объемы оперативной памяти, превышающие 4 Гигабайта. Mac Pro поддерживает расширение оперативной памяти до 16 Г. Если использовать только чипы, "благословленные" инженерами Apple. Xeon Xserve штатно расширяется до 32 Г. И это только начало.
Вся тяжесть этой революции легли на плечи инженеров Apple. "Тигр" поставлялся в двух вариантах - для Intel и для PowerPC. "Леопард" поставляется сразу с 4-мя вариантами исполняемого кода - 32 и 64-битными для PowerPC, и 32 и 64-битными для Intel. Это касается большинства библиотек, многих программ и утилит, и много-много чего еще.
Тем, кто пишет программы для предметных областей, в которых размер данных запросто может превышать 2 Гигабайта, тоже достанется. Зато после этого перехода их жизнь упростится.
От 64-битности выиграют и программы с "нескромными" потребностями в объеме оперативной памяти, превышающими 4Гб. Скромные потребности - это когда меньше... Гигабайт, два, от силы - три...
Ядро операционной системы тоже остается 32-битным, что нисколько не мешает ему успешно "рулить" и 32- и 64-битными процессами. В нем произошли "серезные, но консервативные, изменения". Тем не менее, в драйверы устройств и расширения ядра придется внести некоторые изменения (чтобы они могли работать и с 64-битными "клиентами").
64-битная графика доступна только программам, написанным в Cocoa - и это открывает новые возможности перед компаниями, которые до сих пор оставались на "вторых ролях". Выиграет ли графическая программа от 64-битности, если все библиотеки системы, работающие с графикой, поддерживают 64-битность (обеспечивая большую точность, позволяя работать с графикой намного больших размеров, и т.п.)?
С пределами 32-битной графики уже сталкивался даже я, в своей программе "с очень скромными" потребностями (их всегда можно обойти, но... чем проще, тем надежнее). То есть, "ДА!"
Достанется и "сторонним" разработчикам компиляторов... но люди это всё бывалые и закаленные, они справятся. Это им только на пользу.
Тем, кто отважится идти в беспредельно огромный "новый" мир, "с нуля", будет легче. Чтобы начать новую программу как 64-битную, требуется перевести пару "рубильников" в среде разработки в положение "64" (или "64 и 32"), и внимательно читать документацию. Программирование в 64-битном пространстве имеет свою специфику, но оно ничуть не сложней, чем обычное.
"Чисто" 64-битные программы не смогут работать на 32-битных Маках. Но можно настроить среду разработки на одновременную генерацию и 32-, и 64-битного кодов, отдельно для PowerPC и для Intel. Разработчики особо жадного софта уже сейчас могут решить поддерживать только 64-битные Маки, и только с процессором Intel - в расчете на то, что через сколько-то недолгих лет останутся только они...
Революция потребовала для своего осуществления сотни инноваций, внедренных очень чисто и аккуратно - но в списке из 302 "официальных" на страничке "http://www.apple.com/macosx/features/300.html", 64-битность упоминается только один раз, в разделе про UNIX. Скромно...
2. Interface Builder 3.0
Interface Builder впервые появился в составе в NeXTstep версии 0.8.0, в 1988 году. В 1988 году он был одним из первых WYSIWYG интерфейсных компоновщиков в индустрии. И с тех пор, вплоть до Mac OS 10.5, он оставался почти неизменным (постепенно улучшаясь - но никогда радикально). Уже в Mac OS 10.0 в нем ощущался некоторый аромат старины. И все-таки, несмотря ни на что, он очень хорошо справлялся с тем, для чего предназначен.
В нем были странности. Особенности, к которым надо было привыкнуть. Слабости, с которыми приходилось мириться. И... при всем при этом, мы любили его.
Простите мне употребление прошедшего времени. Interface Builder 3.0, хотя его и называют "новой версией" - это совершенно другой Interface Builder. Он также непохож на Interface Builder последней предыдущей версии, как локомотив сверхскоростной железной дороги (в Германии, Франции или Японии) не похож на паровоз серии "О".
Изменился интерфейс. Он стал... последовательнее, логичнее, многообразнее. Никак не пойму, потеряли ли мы что-нибудь из прежних могуществ. Все вроде на месте. Как и прежде мы можем устанавливать связи между объектами. Как и прежде, мы можем "проиграть интерфейс" в тестовом режиме - как если бы он уже был готовой программой.
Interface Builder имеет дело не с абстрактными структурами данных (из которых программа-потребитель ресурсов должна создавть "живые" объекты), а с самыми настоящими объектами, из которых прямо в компоновщике можно собирать взаимосвязанные сети объектов, определять правила их взаимодействия, пробовать их "в деле". И чего только нельзя было делать с этими объектами!
Едва ли не целые программы можно создавать в Interface Builder, не написав при этом ни единой строчки кода.
Впервые за долгие годы, которые Interface Builder существует на свете, его третью версию сопровождает подробный, и хорошо написанный учебник. Очень может оказаться, что некоторые из инноваций, которым мы так радуемся сегодня, появились уже давно - просто никто о них ничего не знал.
Перетянув из "библиотеки" (в старых версиях это окно называлось "палитрой") объект какого-нибудь класса (например, окно, или кнопку, или целый видео-монитор), мы можем его настроить, как нам хочется - и затащить обратно в окно библиотеки. И использовать его, как если бы это был обычный библиотечный элемент. Элементы библиотеки можно группировать по своему произволу (этого раньше не было), и вообще - организовывать свое рабочее пространство как угодно.
Теперь можно одновременно редактировать общие параметры целых групп объектов, задавать (и пробовать в тестовом прогоне внутри компоновщика) визуальные эффекты и анимацию объектов. Встроена поддержка рефакторинга. Введен новый, текстовый, формат ресурсного файла (xib). Предназначенный в первую очередь для облегчения жизни систем сорс-контрола и программистов, он может оказаться полезным, например, для локализаторов...
Apple просит программистов "не вносить вручную изменения в xib-файлы" - да разве же кто-то послушает?
Согласен - вносить такие изменения нужно осторожно. А что в нашем ремесле не требует осторожности?
Многие изменения в Interface Builder 3.0 выглядят как воплощение самых заветных желаний. Между тем, среди 302 инноваций, перечисленных и вкратце описанных на страничке "http://www.apple.com/macosx/features/300.html", Interface Builder 3.0 упоминается... всего один раз.
В разделе про Xcode 3.0. И только за то, что теперь Interface Builder позволяет программистам прямо в нем "добавлять" в интерфейс своих программ движение и эффекты. Самое важное осталось за кадром.
Продолжение следует...
