KiCad 5 : скриптинг. Терминологическое.
TL;DR То, что я пытался запускать - это вообще не плагин с точки зрения кикада.
Как заведено среди некоторых разработчиков, куча разных вещей могут называться одним и тем же именем, лишь бы "в ту степь" было. Вот и авторы кикада не избежали этой пагубной тенденции.
Для начала, словом "плагин" в кикаде называется вообще всё, что носит хоть какие-то черты модульности, начиная от BOM-плагинов для eeschema (которые вообще не плагин, а внешняя программа, читающая netlist) и заканчивая внутреними модулями для чтения своих собственных, geda'овских и eagle'вских pcb, которые модули тоже в коде называются плагинами. Не избежали этой участи и питоновые скрипты, которых то тут, то там зовут плагинами1.
Всё это конечно очень облегчает гуглинг, да.
Конкретно скриптовые плагины.. да задолбало уже.. пусть будут просто скрипты. Так вот, скрипты описаны (ну как описаны, пара примеров приведена) в главе "Kicad Scripting System" в документе по pcbnew. Представляют они собой, натурально, питоновые скрипты, которые запускаются очень простым способом - вызывается встроенный питоновый движок, которому скармливается строка "import вотэтовот" - далее всё как в настоящем питоне. Именно в виде этих скриптов пишется большая часть расширений к кикаду и именно они представляют основной интерес.
Пока не забыл. Еще один момент, чтобы далее уже совсем ничему не удивляться: KiCad предусматривает два типа скриптов2: Action Plugins и Footprint Wizards. Первые перечисляются в том самом меню с пунктом "Refresh Plugins", вторые видны только из footprint editor'а и служат для процедурной генерации (как нетрудно догадаться) различных полунестандартных футпринтов. Мякотка в том, что некоторые методы в API pcbnew обозваны как wizards (например GetWizardsSearchPath), а некоторые как plugins (например LoadOnePlugin). Хотя относятся к одной и той же сущности. Я всё понимаю: исторические наслоения, но блин, но блин....
1. Лирическое отступление №1: есть и еще один, совсем отдельный тип плагинов, который служит для построения 3d-сцен и ему даже посвящен отдельный раздел документации под названием "KiCad Plugin System", но речь совсем не о них.
2. Лирическое отступление №2: в кикаде нет (в части именно скриптов, что там с 3d и остальным я не смотрел) никаких, характерных для плагинных систем, конструкций с навороченным late binding и запросами вида "дай мне интерфейс такого-то класса". Предусмотрено ровно два (см выше) суперкласса от которых скриптовый код должен наследоваться; единственное что делают классы - регистрируют себя в двух заранее предусмотренных списках. То есть это не полиси, модифицируемая конкретными механизмами, никакие не контекстные действия, а тупо и незатейливо две разновидности скриптов, вызываемых в конкретных ситуациях. Есть правда зачатки третьей разновидности, называемой "File Plugin", но там пока просто заглушка.
Чтобы закрыть эту тему скажу следующее: я лично в этой системе вижу набор скриптов, отчаянно пытающийся стать настоящей плагинной системой. С одной стороны, совершенно недостаточно положить в заранее предусмотренное место™ скрипт, безусловный список которых бы держала система, и которым она же бы выдывала при запуске весь нужный контекст (как бы делал я) - нужно предпринимать специальные действия для того чтобы тебя вообще опознали3. А с другой - для двух видов скриптов, сводящихся к методу "run" всё это совершенно избыточные телодвижения.
Короче говоря, нормальный уровень средневекового зверства4. И не с таким люди живут.
3. Если делать в лоб - например, позвать pcbnew.GetBoard() не в методе, а просто в теле скрипта - будет бумс, просто потому что в момент загрузки никакого "board" еще нету. Ну и так далее в таком духе.
4. Очень было бы забавно выяснять всё это без отладочной консоли (см прошлый пост).
This entry was originally posted at https://ex0-planet.dreamwidth.org/69362.html. Please comment there using OpenID.
Как заведено среди некоторых разработчиков, куча разных вещей могут называться одним и тем же именем, лишь бы "в ту степь" было. Вот и авторы кикада не избежали этой пагубной тенденции.
Для начала, словом "плагин" в кикаде называется вообще всё, что носит хоть какие-то черты модульности, начиная от BOM-плагинов для eeschema (которые вообще не плагин, а внешняя программа, читающая netlist) и заканчивая внутреними модулями для чтения своих собственных, geda'овских и eagle'вских pcb, которые модули тоже в коде называются плагинами. Не избежали этой участи и питоновые скрипты, которых то тут, то там зовут плагинами1.
Всё это конечно очень облегчает гуглинг, да.
Конкретно скриптовые плагины.. да задолбало уже.. пусть будут просто скрипты. Так вот, скрипты описаны (ну как описаны, пара примеров приведена) в главе "Kicad Scripting System" в документе по pcbnew. Представляют они собой, натурально, питоновые скрипты, которые запускаются очень простым способом - вызывается встроенный питоновый движок, которому скармливается строка "import вотэтовот" - далее всё как в настоящем питоне. Именно в виде этих скриптов пишется большая часть расширений к кикаду и именно они представляют основной интерес.
Пока не забыл. Еще один момент, чтобы далее уже совсем ничему не удивляться: KiCad предусматривает два типа скриптов2: Action Plugins и Footprint Wizards. Первые перечисляются в том самом меню с пунктом "Refresh Plugins", вторые видны только из footprint editor'а и служат для процедурной генерации (как нетрудно догадаться) различных полунестандартных футпринтов. Мякотка в том, что некоторые методы в API pcbnew обозваны как wizards (например GetWizardsSearchPath), а некоторые как plugins (например LoadOnePlugin). Хотя относятся к одной и той же сущности. Я всё понимаю: исторические наслоения, но блин, но блин....
1. Лирическое отступление №1: есть и еще один, совсем отдельный тип плагинов, который служит для построения 3d-сцен и ему даже посвящен отдельный раздел документации под названием "KiCad Plugin System", но речь совсем не о них.
2. Лирическое отступление №2: в кикаде нет (в части именно скриптов, что там с 3d и остальным я не смотрел) никаких, характерных для плагинных систем, конструкций с навороченным late binding и запросами вида "дай мне интерфейс такого-то класса". Предусмотрено ровно два (см выше) суперкласса от которых скриптовый код должен наследоваться; единственное что делают классы - регистрируют себя в двух заранее предусмотренных списках. То есть это не полиси, модифицируемая конкретными механизмами, никакие не контекстные действия, а тупо и незатейливо две разновидности скриптов, вызываемых в конкретных ситуациях. Есть правда зачатки третьей разновидности, называемой "File Plugin", но там пока просто заглушка.
Чтобы закрыть эту тему скажу следующее: я лично в этой системе вижу набор скриптов, отчаянно пытающийся стать настоящей плагинной системой. С одной стороны, совершенно недостаточно положить в заранее предусмотренное место™ скрипт, безусловный список которых бы держала система, и которым она же бы выдывала при запуске весь нужный контекст (как бы делал я) - нужно предпринимать специальные действия для того чтобы тебя вообще опознали3. А с другой - для двух видов скриптов, сводящихся к методу "run" всё это совершенно избыточные телодвижения.
Короче говоря, нормальный уровень средневекового зверства4. И не с таким люди живут.
3. Если делать в лоб - например, позвать pcbnew.GetBoard() не в методе, а просто в теле скрипта - будет бумс, просто потому что в момент загрузки никакого "board" еще нету. Ну и так далее в таком духе.
4. Очень было бы забавно выяснять всё это без отладочной консоли (см прошлый пост).
This entry was originally posted at https://ex0-planet.dreamwidth.org/69362.html. Please comment there using OpenID.