Russian Qt Forum

Нужно было реализовать в одном приложении автозапуск под мак ос, как всегда полез в интернет за полезной инфой. Полезного нашел не очень много, в основном холивар на тему: "А нафиг это нужно пускай юзверь сам делает". Сам не сам ,а задачу решать нужно, начал копать что есть,  и есть достаточно примеров с использованием Object-C. Я уже даже немного отчаялся, да есть технология впиливания Object-C кода в С++(Qt) код, но не хотелось это делать в небольшом проекте. В итоге узнал где хранить авторан в маке и у меня родилось вот такое решение для авторана под маком для Qt

 

Выкладываю это решение так как сам потртил прилично времени на поиск, надеюсь кому то поможет :)

P.S. Ссылка на верное решение (http://zalip.org/post/398/)

это делается элементарно и не требует никаких танцев с бубном. не понимаю зачем использовать какие-то хаки если есть нормальное готовое решение.

А можно на него посмотреть ?  :) А то пришлось изобретать вот такую тему ибо решения найти неполучилось.

выкладывай пример :)

Objective-C код помещаешь в файл .m (или .mm, если нужно еще и плюсовой код там вызывать) и добавляешь его в секцию OBJECTIVE_SOURCES в .pro

Ну я читал пост http://www.prog.org.ru/topic_13175_0.html и там Igors предлагал использовать LSSharedFileListInsertItemURL. Потом наткнулся на вот такой пример в инете http://cocoatutorial.grapewave.com/tag/lssharedfilelistinsertitemurl/

Тут еще есть один фактор небольшой, мне object-c глаз режет :) Плюс ко всему не силен в нем, поэтому старался найти реализацию на Qt. Ну вроде как не плохо получилась, насколько понял dropbox тудаже пишет данные для авторана.

А насчет


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

конкретно в данном случае Objective-C вообще не нужен – это всё сишные функции, а вместо Foundation (Objective-C) типов можно использовать CoreFoundation (сишные) типы. напишу переделанный код чуть позже.

вот:

C++ (Qt)
void addAppAsLoginItem
{
    // Create a reference to the shared file list.
    // We are adding it to the current user only.
    // If we want to add it all users, use
    // kLSSharedFileListGlobalLoginItems instead of 
    // kLSSharedFileListSessionLoginItems
    LSSharedFileListRef loginItems = LSSharedFileListCreate(NULL, kLSSharedFileListSessionLoginItems, NULL);
    if (loginItems)
    {
        // This will retrieve the path for the application
        // For example, /Applications/test.app
        CFURLRef bundleUrl = CFBundleCopyBundleURL(CFBundleGetMainBundle());
 
        // Insert an item to the list.
        LSSharedFileListItemRef item = LSSharedFileListInsertItemURL(loginItems, kLSSharedFileListItemLast, NULL, NULL, bundleUrl, NULL, NULL);
        if (item)
            CFRelease(item);
        else
            qDebug("failed to add login item");
 
        CFRelease(bundleUrl);
        CFRelease(loginItems);
    }    
    else
        qDebug("failed to obtain login items");
}
 
void deleteAppFromLoginItem
{
    // Create a reference to the shared file list.
    LSSharedFileListRef loginItems = LSSharedFileListCreate(NULL, kLSSharedFileListSessionLoginItems, NULL);
    if (loginItems)
    {
        CFURLRef bundleUrl = CFBundleCopyBundleURL(CFBundleGetMainBundle());
 
        // Retrieve the list of Login Items
        UInt32 seedValue;
        CFArrayRef loginItemsArray = LSSharedFileListCopySnapshot(loginItems, &seedValue);
 
        for (CFIndex i = 0, n = CFArrayGetCount(loginItemsArray); i < n; ++i)
        {
            LSSharedFileListItemRef itemRef = (LSSharedFileListItemRef)CFArrayGetValueAtIndex(loginItemsArray, i);
            // Resolve the item with URL
            CFURLRef url;
            if (LSSharedFileListItemResolve(itemRef, 0, &url, NULL) == noErr)
            {
                bool shouldRemove = CFEqual(bundleUrl, url);
                CFRelease(url);
                if (shouldRemove)
                {
                    LSSharedFileListItemRemove(loginItems, itemRef);
                    break;
                }
            }
        }
 
        CFRelease(loginItemsArray);
        CFRelease(bundleUrl);
        CFRelease(loginItems);
    }
}

но в документации (http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html) я наткнулся на вот такую штуку:

спасибо за пример, позновательно. Думаю после прочтения маковской доки многие вопросы отпадут  :)

Пожалуй займусь "некрофилией"  :) Так как для меня сейчас этот вопрос критичный, имею ввиду автозапуск софта, описал процесс того как правильно делать автозапуск под маком (http://zalip.org/post/398/)

1) в одном случае ты тупо по-сишному приводишь тип, в другом — через бридж. уж определись :)
2) алерты можно запускать одной строкой, нет нужды заводить для этого переменную (ну это больше вопрос стиля). у тебя много переменных, которые используются лишь раз.
3) boundle
4) alreadyRunning = YES; — думаю можно брейк поставить следующей строкой :) еще чуть удобнее можно перечислить массив через enumerateWithBlock (или как-то так, не помню точное название метода)
5) удаление части пути — это извращение какое-то, нельзя как-то по-проще написать?
6) performSelector:withObject:afterDelay: — неужто GCD нельзя использовать? performSelectorы эти — уже прошлый век.
7) ну и ссылку не помешает добавить в первый пост ;)

1. Спасибо, исправил на __bridge - по идее это более верное решение.
2. Подскажи пожалуйста как в одну строчку вызывать ? В примерах обычно как у меня, а мне это самому не очень нравится.
3. Моя вина, исправил.
4. Согласен, сэкономит времени, да и по кодингу будет правильнее.
5. Не представляю как, может если только где то путь хранить к приложению. Не будем же мы надеяться на то, что у всех софт лежит в Applications :)
6. Расскажешь в чем разница ? Почему предпочтительнее использовать GCD.
7. Ссылку добавил :)

2)

C (Mac)
[[NSAlert alertWithMessageText:@"An error ocurred"
                                         defaultButton:@"OK"
                                       alternateButton:nil
                                           otherButton:nil
                             informativeTextWithFormat:@"LSRegisterURL failed"] runModal];

5) а в чем суть этого кода? напиши пример входа и выхода. и разве bundlePath не путь к .app возвращает?
6) на вопрос «почему» толком не отвечу, лучше почитай в эппловской документации. GCD — это более низкоуровневый механизм многопоточности, работающий с блоками вместо селекторов.

2. Спасибо, поправлю у себя.
5. Да bundlePath вернет путь к приложению, но он вернет путь к приложению лаунчеру, а нам нужно запустить сам софт. Не совсем понял насчет входа\выхода.

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

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

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

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

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

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



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

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

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

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

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

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

как жешь, вот


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

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

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

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

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

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

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

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

если я правильно понимаю код, то происходит такое: пусть аппка установлена в /Applications, удаляем 3 (или 4) раза компоненты пути /Applications/myapp.app, и что получается?..
это могут быть специфические требования 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

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


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


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

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

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

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

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

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

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

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


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

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

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];
    }

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

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

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

Попробую, вроде так действительно проще.


Смотрю, да действительно есть выход в нативные ф-ции. Насколько понимаю кнопка отрисовывается в qmacstyle_mac.mm . Даже допустим, что везде в paintEvent я буду дергать нативные ф-ции отрисовки (хотя пока не совсем понимаю как это делать, ибо Qt хоть и рисует нативныеми функциями, но рисует свои кнопки, а не берет системные стили), мне придется переопределить все компоненты, с которыми я собираюсь работать, ради одной функции, как то КПД маловат будет.


Да, есть, вот как выглядит стандартный пример с темами мака

http://joxi.ru/uTA1UxjKTJAUMD-9h_c

а вот меню в QtCreator к примеру

http://joxi.ru/yTA1U_3JTJCPGQSv-ao

Далее скрины стандартных контролов мака

http://joxi.ru/4TA1U_3JTJD0c3lm_Zw
http://joxi.ru/HzE1U_3JTJCPGafCoDs
http://joxi.ru/LDE1U_3JTJBERdfqFPU

Для меня несоответствие на лицо. Даже если мы закрываем глаза на не совсем точные контролы CheckBox и GroupBox , то закрыть глаза на то, что лейбл во многих контролах не на месте, просто не возможно.


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

Вообще если честно не совсем пойму чем спор вызван, пост то про автозагрузку. А уж ее стандартными средствами Qt вы не реализуете, если захотите отправить ваше приложение в App Store.