Чтобы добавлять сообщения и комментарии, .

@OCTAGRAM:
OCTAGRAM

Я как–то проводил инвентаризацию, как бы теоретически можно было писать под Cocoa для Windows:
1. Реализация Cocoa берётся из iTunesInstaller.exe
2. Компилятор либо LLVM, либо LLVM в роли ObjC => C транслятора, затем другим транслятором
3. Оставались только заголовочные файлы, которые, наверное, надо брать из XCode, вот только какой версии, не очень было понятно. Учитывая, как реализована совместимость на уровне машинных кодов в Objective-C, в принципе, можно брать самую новую и просто не использовать слишком новые методы.
Нашёл время провести более детальный анализ того, что же именно содержит Apple Application Support. Во–первых, собственно Objective-C портированных библиотеки там 2: Foundation.dll и CoreFoundation.dll. В закрытых версиях Apple есть несколько типов CoreFoundation, которые без конвертации можно привести к указателю на Objective-C (toll-free bridging). Похоже, что это оно. Если поставить iCloud, там ещё можно отрыть AOSKit.dll, экспортирующий какие–то Objective-C классы. Никаких AppKit нет.
Что касается версии, я немного позанимался дихотомией и пришёл к выводу, что Apple Application Support из iTunes примерно соответствует версиям Lion/Mountain Leopard. Если скачать с сайта ADC xcode462_cltools_10_76938260a.dmg, он же Command Line Tools (OS X Lion) for Xcode — April 2013.dmg, достать оттуда 7-zip'ом Foundation.h и взять этот же файл из command_line_tools_for_osx_mountain_lion_april_2014.dmg, то видно, что, например, добавился #import <Foundation/NSHashTable.h>, и я вижу OBJC_CLASS_$_NSHashTable в Foundation.dll, и для некоторых других новых классов тоже, но не всех. А из Maverick (commandlinetoolsosx10.9forxcode6.2.dmg) я ничего добавленного уже не вижу.
Все остальные библиотеки реализованы более менее без Objective-C. Несколько библиотек, вижу, импортируют несколько вызовов objc.dll, но, похоже, только лишь для того, чтобы поработать с blocks и libdispatch.dll.
Таким образом, реально из iTunes можно взять:
1. Коллекции и связанные с ними Property List сериализаторы
2. Quartz (CoreGraphics), которым, в частности, можно рисовать текст нормально, как на Mac OS X, без радужного замыливания
3. «Официальный» порт libdispatch
Может, ещё какие не–Objective-C библиотеки, коих там куча.
AppKit, видимо, только через GNUStep, Cocotron или YellowBox. Свои интерфейсы Safari и iTunes, видимо, как–то через C'шные библиотеки отрисовывают поверх C'шного Quartz.

В отсутствие AppKit самое интересное (для меня) остаётся в libdispatch. И libdispatch, и libuv решают похожие задачи, но кто из них лучше? У libdispatch на Windows, кроме «официального» порта есть два неофициальных, и неплохо бы было, чтобы кто–нибудь посравнивал их между собой на предмет проблемы C10k.

@OCTAGRAM:
OCTAGRAM

А вот скажите мне, кто–нибудь видел хорошие приложения на интерфейсе WPF? Дайте ссылку. Мои индивидуальные впечатления таковы, что я в восторге от Cocoa, вплоть до того, что даже на Windows хотел бы научиться делать приложения на выдранной из iTunes реализации от Apple; чуть хуже, но всё ещё приятен XUL, вот только мороки с ним много. В целом, позитивные впечатления от wxWidgets и SWT. На этом список тулкитов, к которым я отношусь хорошо, заканчивается.
Если не вытрёпываться и по какой–то причине wxWidgets и SWT не подходят, то на худой конец сгодится Qt или Swing. На WinAPI и Gtk+ получается параша.

То, что я видел на WPF (INTUIT и VK — это WPF, если я всё правильно понял) — где–то посередине между худым концом и парашей.

@OCTAGRAM:
OCTAGRAM

Windows 7: Inside the Ultimate Control Panel
В экосистеме Cocoa/GNUStep/и т. д. в порядке вещей давать расширения не только файлам, но и директориям, и там это очень правильно сделано. Программы–директории, в них могут быть библиотеки–директории, рядом могут быть папки–плагины, а ещё драйвера в Mac OS X оформлены папками. Трюком, описанным в статье, можно и Windows заставить папки воспринимать как нечто цельное. Или изменить значок и способ обработки по умолчанию, оставив возможность смотреть внутрь. Пригодится, если я буду портировать GNUStep на SOM.

Мне не нравится, как в YellowBox, Safari и iTunes исполняемые файлы и динамические библиотеки вываливаются из своих директорий. Это портит всю идею. В Windows уже давно есть возможность через манифесты порулить процессом поиска dll, так что при помощи обоих трюков должно быть возможно сделать всё как в Mac OS X

@borunov:
borunov

написал для мака программку. считает количество недель от сегодня до ДР+75 лет (к примеру) и выводит в системный трей. так сказать, напиминание о том что время кончается.. dl.dropbox.com

@borunov:
borunov

и снова прошу помощи зала. MacOS X. Cocoa. Document-based application. унаследовал NSApplication что бы переписать обработчик событий sendEvent:
вопрос: как, находясь в экземпляре класса MyApp (наследника NSApplication) обратиться к экземпляру (экземплярам) класса Document (наследника NSDocument)?
спасибо.

@borunov:
borunov

подскажите, пожалуйста. Cocoa. есть массив, который я вычислениями обрабатываю. хочу его обрабатывать, но если юзеру надоело ждать (а он большой) он жмет кнопку и получает результат "с полпути". как это сделать?
в идеале бы я обсчитал элемент, сказал кому-то вызови меня (встал в конец очереди событий), мышка поползала, кнопки нажались (или не нажались) и я снова обсчитываю элемент. как это сделать?
или как по другому реализовать это?
спасибо

@HeX:
HeX

Подхожу я такой к классу UIVIEW и говорю "Запили мне объект View, который будет основным представлением, быыыыстра блять!". А он мне с вертушки в щи поясняет: "Иди нахуй, долбоеб, уже все сделано до тебя, не еби мозг." И я такой "Лааааадно".
Вот оно ваше ООП под гейОС — компилятор все сделает, не забывай мышкой по экрану возить.

@Gordio:
Gordio

В догонку #1594404
Апокалипсис отменяется, оказывается "How would you create a pointer to a single bit? You can't. But you can create a pointer to a byte." Что говоря на нашем: Байт потому что указатели. =D

@Gordio:
Gordio

Это же ужас. "BOOL в Objective-C в действительности представляет собой" typedef signed char — это байт, тобишь 8 бит, куда же остальные 7 бит уходят? Нихарашо!

@moogeek:
moogeek

Собираюсь изучать Objective-C в связке с Xcode и Cocoa. С чего начать? Подскажите хорошую книгу, пожалуйста

@develar:
develar

В чем красота девушки? В аллоцированом ли размере буфера? Нет. В гармонии. В целостности. Стройности всей концепции в целом. Это плюс всех ОО программ — поняв философию, ты понимаешь всю сущность целиком, и она становится родной — интуитивно понятной и близкой.

someuser спросил — "слушай я помню ты где-то писал про реализацию Targets&Actions на AS3. Не мог бы ты рассказать в чем там суть, и чем это лучше обычных эвентов существующих во AS3?" Без контекста — эта фраза повод для увольнения того, кто будет только из-за некой абстрактной субъективной красоты реализовывать концепцию Cocoa Targets and Actions developer.apple.com

Штука в том, что в Cocoa меня не касается тип Control. Чтобы быть извещенным об изменении control или же получить/установить значение из/в, мне не надо знать, ColorPicker это, или PushButton. Нет кучи каких-то специфичных событий и нет кучи каких-то специфичных getters/setters. Если я хочу поцеловать девушку — я поцелую ее ровно также, как и носорога.

Прелесть в декларативности и высокоуровневости. github.com Да, свойство set action есть только одно, то есть если у меня есть PushButton, то только кто-то один будет слушать нажатие на нее. Так ведь этого-то и достаточно — я хочу лишь поцеловать девушку — я не собираюсь жениться и ее отношение к вырубке лесов в Антарктике меня не касается.

@develar:
develar

В тему #752034 — в Cocoa компонент disabled не просто alpha в 0.5, а с неким вывертом — типа colorpicker отображает белый цвет или пропадает текст в NumericStepper (то есть некоторое хитрое поведение) и при этом label самих control остается тем же цветом/прозрачностью. И вот если тупо disable весь контейнер как отключение мыши и alpha в 0.5, то ведь и не будет оповещения всех компонентов о том, что они то disabled by parent.

@develar:
develar

Почему Apple не выпускает плагин к IB для iLife controls — HUD?

@develar:
develar

В Cocoa и Flex разный подход для обеспечения изменения состояние ToggleButton — к примеру, вам нужно чтобы при toggled был иной toolTip/icon. Во flex вы можете или воспользоваться states в mxml, или городить кучу кода в as. В Cocoa же все лаконичнее (читабельнее), логичнее и удобнее (с точки зрения разработчика как клиента библиотеки) — вы можете просто задать alternateImage/alternateTitle и все — вас не касается что там под капотом и как, хоть в чистом AS, хоть в MXML это будет работать.

@develar:
develar

ммм... архитекторы cocoa. Проблема курицы и яйца решена изящно. Штука в том, что во flex собственно некий друг, типа Window, имеет скин, который и определяет непосредственно contentGroup, куда будут вставляться дети. Штука только в том, что получается так, что window и так содержит всегда одно дите — тот Container (Box или Group, как вам угодно) что и определяет контент экрана окна (мы ведь не идиоты, чтобы как Adobe пихать в Application main непосредственно весь код, он есть контроллер, а мы потом благодаря такому может одним движением мыши перекинуть такой контейнер куда-угодно — хоть в состав некого композитного компонента, хоть в NativeWindow для AIR). И получается, что не скин говорит хост-компоненту куда вставлять детей, а хост-компонент говорит скину, что вот тебе сontentView — resize&move его. Красота. Cocoa API сказка.

@develar:
develar

архитектура доставляет. NSControl представляет собой по сути обертку над NSCell. Таким образом, при вставке в NSSegmentedControl 20 кнопок, мы сэкономим на 20 NSControl, и так даром не нужных — ведь всю работу в данном случае осуществляет именно parent hostComponent. Переводя на понятный флексерам язык, это означает, что если в ButtonBar мы вставляем 20 кнопок, мы не будем создавать 20 Button (даже если использовать astra.thewebproduction.com:8443 , все равно оверхед), а сразу заюзаем их скины.

@kekssw:
kekssw

хрен с ним, с самим планшетником. вот каких вкусняшек в SDK 3.2 притащили! сходу три-четыре мегаполезные для жуйклиента фичи (менюшки/попапы, абсракция над жестами, регэкспы) при беглом осмотре чейнджлога. всякие прочие (файл-шаринги, документы, генерация PDF'jd, ...) тоже вкусны, но неприменимы в данном случае

@develar:
develar

Правильно ли я понимаю, что всякие там Swing и Cocoa ничтожество по сравнению с Flex 4 (is awesome ;)) (нюанс убожества реализации прекрасной идеи скинования в flex 4 оставим на совести Adobe), так как Flex позволяет нам отскиновать не только LaF (F немного под вопросом и по большей части нормально только путем создания (путем наследования или полностью), но не просто кастомизацией (CSS, хотя и тут в flex 4 есть подвижки в виде перемещения ряда свойств в стили))? Или типа это мнимое преимущество тотального перескинования (путем подмены skin part implementation и перекомпоновки — я никогда не имел дело с нормальными widget toolkits — у вас там в раю в Swing/Cocoa как там дело с этим?) не стоит потери фичи Interface Builder (или типа фича Interface Builder получается, но фактически иной философии — не 1, а n может быть вариаций компоновки (плюс эта n дробится на еще на sub n из-за декомпозиции компонентов (так как скин привязан к компоненту)))?

@kekssw:
kekssw

Кто бы научил динамически
рисовать менее отстойне CellView. Не хочу в фотошопе, хотя весь мир,
похоже, считает что нужно именно так :(

@kekssw:
kekssw

в течении 2-х часов пытался понять причину EXC_BAD_ACCESS. интернеты похоже уверены что такое бывает только если сделать лишний [object release] ну или в крайнем случае — не сделать необходимого [object retain]. довел простенькую программку до состояния, когда методы для работы с памятью не использовались совсем, и только после этого осознал, что ошибка кроется на стыке Interface Builder'а и ручного кодинга. вообще похоже я единственный извращенец, старающийся взять лучшее из обоих способов, так что предвижу море граблей подобного рода в будущем. ну зато понимание фреймворка еще немного улучшилось.