Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Спасибо за статью.
С плагинами в QtCreator всё красиво и понятно, кроме одного — распространять плагин хочется в бинарном виде (что бы потребители не заморачивались).
А для этого нужно вытаскивать исходники QtCreator'а, собирать его нужным компилятором и в итоге получается плагин для одной платформы и одного компилятора. И так для всех платформ и компиляторов.
В качестве идеи предлагаю следующее:
Может можно создать для QtCreator'a один плагин, который будет грузить рядом лежащий *.qml или *.js файл и исполнять его в окружении QtCreator'а. Если в QScriptingEngine зарегистрировать точки доступа к QtCreator API, то можно будет разрабатывать плагины на JavaScript и поставлять только текстовые файлы (*.qml или *.js) для любой конфигурации QtCreator'а.
Прошу прощения, если сморозил глупость: о)
С плагинами в QtCreator всё красиво и понятно, кроме одного — распространять плагин хочется в бинарном виде (что бы потребители не заморачивались).
А для этого нужно вытаскивать исходники QtCreator'а, собирать его нужным компилятором и в итоге получается плагин для одной платформы и одного компилятора. И так для всех платформ и компиляторов.
В качестве идеи предлагаю следующее:
Может можно создать для QtCreator'a один плагин, который будет грузить рядом лежащий *.qml или *.js файл и исполнять его в окружении QtCreator'а. Если в QScriptingEngine зарегистрировать точки доступа к QtCreator API, то можно будет разрабатывать плагины на JavaScript и поставлять только текстовые файлы (*.qml или *.js) для любой конфигурации QtCreator'а.
Прошу прощения, если сморозил глупость: о)
Если ваш плагин действительно интересен его можно добавить в основной репозитарий Qt Creator и тогда он будет расспространятся и собираться под все платформы вместе с ним. Но придется попотеть, чтобы все соответсвовало требованиям.
Я об этом и говорю — много мороки.
а тут бац — текстовые файлы и никаких пересборок. Понравился плагин — скачал 3Kb текстовый файл и пользуйся на здоровье.
Существенное облегчение в распространении плагинов налицо (это как с python, порог вхождение невысок, легко разрабатывать и пользоваться, отсюда куча полезных инструментов и программ на нём).
а тут бац — текстовые файлы и никаких пересборок. Понравился плагин — скачал 3Kb текстовый файл и пользуйся на здоровье.
Существенное облегчение в распространении плагинов налицо (это как с python, порог вхождение невысок, легко разрабатывать и пользоваться, отсюда куча полезных инструментов и программ на нём).
Например так было с плагином TODO. Другой пример — с версии QtCrator 3.1 Artistic Style Plugin частично вошел в состав QtCreator в виде плагина Beautifying Source Code). Приведенные же в статье плагины скорее «Just for Fun» и никто их естественно не будет добавлять в основной репозиторий.
Отличная идея, именно так (насколько мне известно) и делают для того, чтобы создать систему расширений в приложении, но вызывает вопрос следующее:
Ведь мы можем определить интерфейс доступа к QtCreator api (который, к слову сказать, периодически изменяется и его еще нужно поддерживать), а как при этом быть с другими функциями, которые возможно новый плагин захочет использовать?
На самом деле сборок получается не так и много: одна для Windows (так как для x64 и x32 используется MSVS 2010 x32), одна для Linux x64, одна для Linux x32 и одна для Mac OS X — всего четыре. Если, к примеру, в Windows системе установить виртуальную машины Linux x32, x64 и MacOSX а папку с исходниками расшарить за счет «Guest Additions», то сборка всех плагинов сводится к переключению между машинами и запуску сборки-тестировании (ну и сборе всех версий плагинов в одном месте). Если это все автоматизировать (вплоть до написания серверов для виртуальных машин, которые будет получать команды и запускать сборку), то весь процесс (по идее) не займет много времени.
Если в 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, поэтому могу высказывать лишь свои предположения. А вы решите — реальный это вариант или нет.
Этот довод касается и всех существующих плагинов — они могут «ломаться» при смене API. Если в API используются QObject derived классы, то протолкнуть их в скриптинг очень просто — зарегистрировать под какими-то именами все синлтоны (хотя я смотрю там используются в основном статические функции а ля Core::ModeManager::addWidget).
Опять таки, это проблема скриптинга. Как мне использовать какую-либо полезную функцию в скриптинге? Либо библиотека позволяет зарегистрировать свой API в скриптинге, либо надо это делать за неё посредством proxy библиотеки. Может быть в Qt есть единый подход для регистрации API в скриптинге (например, библиотека должна экспортировать функцию void initScripting(QScriptEngine* engine); )
Ведь мы можем определить интерфейс доступа к 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.
А вообще было бы неплохо сделать 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
Linux x86_64 вроде не забыт: отдельно для этой платформы собираю плагины, например для плагина контроля аудио Linux_x64. Просто обозначение принято x64 (как и на странице загрузки), вместо x86-64
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование панели режимов QtCreator + 2 плагина