Как стать автором
Обновить

Комментарии 9

Спасибо за статью.
С плагинами в QtCreator всё красиво и понятно, кроме одного — распространять плагин хочется в бинарном виде (что бы потребители не заморачивались).
А для этого нужно вытаскивать исходники QtCreator'а, собирать его нужным компилятором и в итоге получается плагин для одной платформы и одного компилятора. И так для всех платформ и компиляторов.
В качестве идеи предлагаю следующее:

Может можно создать для QtCreator'a один плагин, который будет грузить рядом лежащий *.qml или *.js файл и исполнять его в окружении QtCreator'а. Если в QScriptingEngine зарегистрировать точки доступа к QtCreator API, то можно будет разрабатывать плагины на JavaScript и поставлять только текстовые файлы (*.qml или *.js) для любой конфигурации QtCreator'а.

Прошу прощения, если сморозил глупость: о)
Если ваш плагин действительно интересен его можно добавить в основной репозитарий Qt Creator и тогда он будет расспространятся и собираться под все платформы вместе с ним. Но придется попотеть, чтобы все соответсвовало требованиям.
Я об этом и говорю — много мороки.
а тут бац — текстовые файлы и никаких пересборок. Понравился плагин — скачал 3Kb текстовый файл и пользуйся на здоровье.
Существенное облегчение в распространении плагинов налицо (это как с python, порог вхождение невысок, легко разрабатывать и пользоваться, отсюда куча полезных инструментов и программ на нём).
Например так было с плагином TODO. Другой пример — с версии QtCrator 3.1 Artistic Style Plugin частично вошел в состав QtCreator в виде плагина Beautifying Source Code). Приведенные же в статье плагины скорее «Just for Fun» и никто их естественно не будет добавлять в основной репозиторий.
Отличная идея, именно так (насколько мне известно) и делают для того, чтобы создать систему расширений в приложении, но вызывает вопрос следующее:
Если в QScriptEngine зарегистрировать точки доступа к QtCreator API

Ведь мы можем определить интерфейс доступа к QtCreator api (который, к слову сказать, периодически изменяется и его еще нужно поддерживать), а как при этом быть с другими функциями, которые возможно новый плагин захочет использовать?

На самом деле сборок получается не так и много: одна для Windows (так как для x64 и x32 используется MSVS 2010 x32), одна для Linux x64, одна для Linux x32 и одна для Mac OS X — всего четыре. Если, к примеру, в Windows системе установить виртуальную машины Linux x32, x64 и MacOSX а папку с исходниками расшарить за счет «Guest Additions», то сборка всех плагинов сводится к переключению между машинами и запуску сборки-тестировании (ну и сборе всех версий плагинов в одном месте). Если это все автоматизировать (вплоть до написания серверов для виртуальных машин, которые будет получать команды и запускать сборку), то весь процесс (по идее) не займет много времени.
Честно сказать я не сильно разбирался с системой плагинов для QtCreator, поэтому могу высказывать лишь свои предположения. А вы решите — реальный это вариант или нет.

Ведь мы можем определить интерфейс доступа к QtCreator api (который, к слову сказать, периодически изменяется и его еще нужно поддерживать)

Этот довод касается и всех существующих плагинов — они могут «ломаться» при смене API. Если в API используются QObject derived классы, то протолкнуть их в скриптинг очень просто — зарегистрировать под какими-то именами все синлтоны (хотя я смотрю там используются в основном статические функции а ля Core::ModeManager::addWidget).

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

Опять таки, это проблема скриптинга. Как мне использовать какую-либо полезную функцию в скриптинге? Либо библиотека позволяет зарегистрировать свой API в скриптинге, либо надо это делать за неё посредством proxy библиотеки. Может быть в Qt есть единый подход для регистрации API в скриптинге (например, библиотека должна экспортировать функцию void initScripting(QScriptEngine* engine); )
Как минимум для Windows есть еще MSVS 2012 x32 и MinGW x86_32. Да и Linux x86_64 не понятно почему забыт… Итого вроде 7 уже получается.
А вообще было бы неплохо сделать api для PySide.
В доступных для скачивания дистрибутивах Qt под Windows (MSVS 2012 x32/x64, MinGW x86_32, etc) QtCreator собран с MSVS 2010 x32 (ревизия 27d10d8dcd), поэтому и потребуется одна сборка (если же пользователь сам собрал QtCreator с MinGW, то собрать плагин ему не составит труда).
Linux x86_64 вроде не забыт: отдельно для этой платформы собираю плагины, например для плагина контроля аудио Linux_x64. Просто обозначение принято x64 (как и на странице загрузки), вместо x86-64
Спасибо за рзъяснение, не знал что везде MSVS 2010… Про 64-bit Linux прошу прощения, невнимательно читал, пропустил. Скорее всего именно потому что обозначение x64 непривычно в Linux мире.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории