[Пост] Автозапуск под маком

[Old]

Ну вот я усердно учил "classic" полагая что "свой ОС  надо знать" и все такое. Но пришел Carbon.

Что это все такое: "classic", Carbon? Я про такие ОС никогда не слыхал.

[kambala]

classic — это версии Mac OS до X, а Carbon — родной С++-фреймворк (типа винапи), который использовался в этих «классических» ОС (сейчас используется фреймворк Cocoa и язык Objective-C).

2Igors: я занимаюсь разработкой под iOS, поэтому от нативняка деться никуда не могу (но скоро планирую опробовать Qt). а Cocoa Touch и Cocoa, к счастью, связаны довольно тесно.

[ecspertiza]

в посте из последнего куска кода: вход — path, выход — newPath. и аналогично для appPath.

Блин, сейчас вчитался в код, там походу вообще можно удалить кусок

Код:

    NSString *appPath = [[[[[[NSBundle mainBundle] bundlePath] stringByDeletingLastPathComponent] stringByDeletingLastPathComponent]  stringByDeletingLastPathComponent] stringByDeletingLastPathComponent];
    // get to the waaay top. Goes through LoginItems, Library, Contents, Applications
    [[NSWorkspace sharedWorkspace] launchApplication:appPath];
    //[[NSWorkspace sharedWorkspace] launchApplication:@"AutoStart.app"];
    NSLog(@"AutoStartHelper: App path:%@",appPath);
    
    [NSApp performSelector:@selector(terminate:) withObject:nil afterDelay:0.0];

[off]Мне тоже приходится делать вещи такого рода, но я всячески увертываюсь и избегаю их до последней возможности - ну только когда уже совсем прижмет... Наблюдая энтузиазм с которым молодые люди очертя голову прямо-таки бросаются в пучину этого кала, хочу заметить: изучение нативняка/потрохов ОС мало что дает программисту. Ну вот я усердно учил "classic" полагая что "свой ОС  надо знать" и все такое. Но пришел Carbon. Тут я уже сообразил и примкнул к кросс-платформенному API (к сожалению не Qt). Ага, ну вот и Carbon на ладан дышит, надо учить какаву. И конца-края этому не будет. Лучше впечатлять содержательностью/ф-ционалом задачи, а всякие "сервисы" - переживет, поверьте, он не оценит их высоко. 
[/off]

К сожалению некоторые вещи можно сделать только нативно, особенно под Мак ОС. Мне тоже не доставляет особого удовольствия ковыряния в object-c, но поставленные задачи решать необходимо. К сожалению Qt не способен из коробки сделать автозапуск приложения.

[Old]

classic — это версии Mac OS до X, а Carbon — родной С++-фреймворк (типа винапи), который использовался в этих «классических» ОС (сейчас используется фреймворк Cocoa и язык Objective-C).

Т.е. Carbon это C++-фреймворк, вместо которого пришел Cocoa, который на Objective-C? И что Carbon выпиливается полностью, его использовать уже нельзя?

2Igors: я занимаюсь разработкой под iOS, поэтому от нативняка деться никуда не могу (но скоро планирую опробовать Qt).

Как правило, и в дальнейшем придется лезть в натив. Пользователи привыкают к каким-то особенностям платформы, которых нет на других, поэтому эти особенности не включают в кроссплатформенные библиотеки. Вот и приходится для каждой платформы учитывать такие мелочи, но это для массовых программ.

[ecspertiza]

Как правило, и в дальнейшем придется лезть в натив. Пользователи привыкают к каким-то особенностям платформы, которых нет на других, поэтому эти особенности не включают в кроссплатформенные библиотеки. Вот и приходится для каждой платформы учитывать такие мелочи, но это для массовых программ.

Более того Qt контролы очень сильно (на вид) отличаются от стандартных маковских. А маководы это замечают сразу, так как они достаточно специфичные пользователи.

[kambala]

в посте из последнего куска кода: вход — path, выход — newPath. и аналогично для appPath.

Блин, сейчас вчитался в код, там походу вообще можно удалить кусок

пример строки-то где?

classic — это версии Mac OS до X, а Carbon — родной С++-фреймворк (типа винапи), который использовался в этих «классических» ОС (сейчас используется фреймворк Cocoa и язык Objective-C).

Т.е. Carbon это C++-фреймворк, вместо которого пришел Cocoa, который на Objective-C? И что Carbon выпиливается полностью, его использовать уже нельзя?

да, все верно. насколько я помню, в последних Xcode и command line developer tools карбоном UI уже не построишь, только Cocoa. но еще не всё сидит на Objective-C: много сишных функций по-прежнему используется (например тот же CoreFoundation)

Qt 5 тоже карбон не поддерживает и не позволяет строить «универсальные» приложения (у которых в бинарнике одновременно присутствуют архитектуры powerpc и intel), а вот Qt 4 еще может. а от powerpc эппл отказалась еще в OS X 10.7 (2 года назад).

[ecspertiza]

пример строки-то где?

как жешь, вот

Qt 5 тоже карбон не поддерживает и не позволяет строить «универсальные» приложения (у которых в бинарнике одновременно присутствуют архитектуры powerpc и intel), а вот Qt 4 еще может. а от powerpc эппл отказалась еще в OS X 10.7 (2 года назад).

Я то надеялся, что они перейдут на Cocoa, и кнопочки будут лучше выглядеть и прочие контролы, у них в этом плане ничего вообще не изменилось ?

[Old]

да, все верно.

И что, они так часто делают? Странно, что еще есть желающие писать для этой платформы...
Хотя... там такое хомячье...
Ну да меня Бог миловал.

[Igors]

classic — это версии Mac OS до X, а Carbon — родной С++-фреймворк (типа винапи), который использовался в этих «классических» ОС (сейчас используется фреймворк Cocoa и язык Objective-C).

Ну не совсем Carbon пришел вместе с OSX, до этого было свое С API - не помню уже как оно все вместе называлось, но по сравнению с ним WinAPI (которым тут недовольны) - то так, детский лепет, курорт.

Т.е. Carbon это C++-фреймворк, вместо которого пришел Cocoa, который на Objective-C? И что Carbon выпиливается полностью, его использовать уже нельзя?

С (без ++), Пока еще Carbon ходит (32-bit only, как-то огородами, все равно через какаву), но это последние вздохи.

Более того Qt контролы очень сильно (на вид) отличаются от стандартных маковских.

Судя по исходникам есть возможность использовать нативные. Напр пройдите в отладчике QPushButton::paintEvent

И что, они так часто делают?

Ну раз 5-6 на моей памяти, может больше.

К сожалению некоторые вещи можно сделать только нативно, особенно под Мак ОС. Мне тоже не доставляет особого удовольствия ковыряния в object-c, но поставленные задачи решать необходимо. К сожалению Qt не способен из коробки сделать автозапуск приложения.

Конечно дело Ваше, но в жгучую необходимость не верится. Добавить в док и поставить галочку "Open at Login" займет меньше полминуты.

[kambala]

пример строки-то где?

как жешь, вот

где?.. я ничего не вижу. в посте нашел только это: NSURL *bundleUrl = [mainBundleURL URLByAppendingPathComponent:@"Contents/Library/LoginItems/AppLauncher.app"];

если я правильно понимаю код, то происходит такое: пусть аппка установлена в /Applications, удаляем 3 (или 4) раза компоненты пути /Applications/myapp.app, и что получается?..

Конечно дело Ваше, но в жгучую необходимость не верится. Добавить в док и поставить галочку "Open at Login" займет меньше полминуты.

это могут быть специфические требования Mac App Store

P.S. вот что осталось от карбона в самом свежем Xcode:
CarbonSound.framework
CommonPanels.framework
Help.framework
HIToolbox.framework
HTMLRendering.framework
ImageCapture.framework
Ink.framework
NavigationServices.framework
OpenScripting.framework
Print.framework
SecurityHI.framework
SpeechRecognition.framework

[ecspertiza]

Конечно дело Ваше, но в жгучую необходимость не верится. Добавить в док и поставить галочку "Open at Login" займет меньше полминуты.

Добавить в док иконку действительно не долго. Но когда начинаешь сталкиваться с требованиями от App Store, оказывается, что половина решений которые ходят в интернете просто не работают. Более того, пример из жизни, нужно было добавить два пункта в контекстное меню проводника, была использована технология о которой писалось в документации, когда мы создаем службы в определенной папке, но после того как наше приложение стало подписано Sandbox, данная техника работать перестала, под одной простой причине, Sandbox запрещал приложению копировать файлы в нужную папку. И что самое интересное так во многом. Насчет paintEvent гляну, но мне кажется у Qt под маком будет как везде, то есть по сути они отрисовывают свои похожие контролы. Возможно для меня или для вас это не важно, но мак пользователи из за своей специфичности это замечают и очень часто пишут по этому поводу гневные письма, более того даже интерфейс на Qml со свистоперделками их не устраивает.

где?.. я ничего не вижу. в посте нашел только это: NSURL *bundleUrl = [mainBundleURL URLByAppendingPathComponent:@"Contents/Library/LoginItems/AppLauncher.app"];

ссылка не вставилась, вот этот кусок http://joxi.ru/_lUwU_3JTJBTcUL7v6w можно удалить.

если я правильно понимаю код, то происходит такое: пусть аппка установлена в /Applications, удаляем 3 (или 4) раза компоненты пути /Applications/myapp.app, и что получается?.

не совсем так, ибо в Applications у нас будет лежать наше приложение, в то время как лаунчер будет лежать по пути (пример)

/Applications/MyApp.app/Components/Library/LoginItem/AppLauncher.app

а так как это совершенно два разных приложения, то и лаунчер получит путь к себе.

[Igors]

Насчет paintEvent гляну, но мне кажется у Qt под маком будет как везде, то есть по сути они отрисовывают свои похожие контролы.

Во всяком случае нативные контролы на Mac существуют, т.е. один QWidget соответствует одному HIView/NSView. Это доступно через winId(), а дальше все в Ваших руках

Возможно для меня или для вас это не важно, но мак пользователи из за своей специфичности это замечают и очень часто пишут по этому поводу гневные письма, более того даже интерфейс на Qml со свистоперделками их не устраивает.

Нормальные пользователи с чувством вкуса, а не самцы с командной строкой

[ecspertiza]

Во всяком случае нативные контролы на Mac существуют, т.е. один QWidget соответствует одному HIView/NSView. Это доступно через winId(), а дальше все в Ваших руках

Все верно, но на одном QWidget приложение не построишь, нужны и тулбары и теже кнопки, радиобатоны, чекбоксы и все в этом роде. Нет никаких припятствий рисовать их самому. Но тогда у меня возникают два вопроса

1. Допустим, я сам отрисовываю кнопки и прочие контролы в стиле мак ос (а это придется делать, так как то что рисует Qt из рук вон выгдядит плохо). Первое на что я натыкаюсь это то, что мне необходимо проделать большой кусок безполезной работы отрисовывая нативные контролы. Что увеличит сроки разработки, но допустим мы с этим смирились, далее выходит новая версия Mac OS Frog в которой создатели этой замечаетльной ОС решили переделать все контролы под другой стиль. И вот уже ваши контролы не нативные. Теперь нам придется либо поддерживать два вида контролов для этой ОС либо смериться с тем, что есть.
2. Теперь представим, что мы отходим от стандартных эллементов управления вообще. Например начинаем рисовать кнопочки с собственными стилями. В таком случае мы получаем огромное количество писем в саппорт, что интерфейс выглядет не нативно. Это реальный случай из жизни софта.

Получается мы стоим на перепутье, либо терпим письма в саппорт, либо берем на себя дополнительные задачи, которые в результате вообще могут оказаться безполезными. Либо у нас есть третий вариант, интерфейс под мак сделать нативным (на контролах Cocoa), при этом ядро приложения оставить то которое было и под остальными ОС.

Нормальные пользователи с чувством вкуса, а не самцы с командной строкой

Ни коем образом не хотел обидеть этих пользователей, лишь говорю что они специфичны, и подходить к разработке под мак, нужно немного иначе.

[kambala]

если я правильно понимаю код, то происходит такое: пусть аппка установлена в /Applications, удаляем 3 (или 4) раза компоненты пути /Applications/myapp.app, и что получается?.

не совсем так, ибо в Applications у нас будет лежать наше приложение, в то время как лаунчер будет лежать по пути (пример)

/Applications/MyApp.app/Components/Library/LoginItem/AppLauncher.app

а так как это совершенно два разных приложения, то и лаунчер получит путь к себе.

теперь понял, спасибо. по-моему проще написать так:

Код

Objective-C
    if (!alreadyRunning) {
        NSString *path = [[NSBundle mainBundle] bundlePath], *contents = @"Contents/";
        NSRange contentsRange = [path rangeOfString:contents options:NSBackwardsSearch];
        NSString *mainAppPath = [[path substringToIndex:contentsRange.location + [contents length]] stringByAppendingString:@"MacOS/LaunchAtLoginApp"];
        [[NSWorkspace sharedWorkspace] launchApplication:mainAppPath];
    }

[Igors]

1. Допустим, я сам отрисовываю кнопки и прочие контролы в стиле мак ос (а это придется делать, так как то что рисует Qt из рук вон выгдядит плохо). Первое на что я натыкаюсь это то, что мне необходимо проделать большой кусок безполезной работы отрисовывая нативные контролы. Что увеличит сроки разработки,

Та посмотрите же QPushButton::paintEvent - там виден выход в нативняк для отрисовки. В момент paintEvent у Вас на руках CGContextRef и NSView - ну и зовите нативную ф-цию рисования. А повторить самому все что OSX рисует - надорветесь.

но допустим мы с этим смирились, далее выходит новая версия Mac OS Frog в которой создатели этой замечаетльной ОС решили переделать все контролы под другой стиль. И вот уже ваши контролы не нативные. Теперь нам придется либо поддерживать два вида контролов для этой ОС либо смериться с тем, что есть.

Ну сказали тоже - ведь есть "themes" и их можно назначать из API.

2. Теперь представим, что мы отходим от стандартных эллементов управления вообще. Например начинаем рисовать кнопочки с собственными стилями. В таком случае мы получаем огромное количество писем в саппорт, что интерфейс выглядет не нативно. Это реальный случай из жизни софта.

Именно этот путь я использую - свой стиль для всего. Забот конечно много, но если это действительно стиль (а не "сборная солянка") - пользователь относится с пониманием.