KiCad Scripting, Цели и пути Опции

[dxp]

Всем привет!

Как известно с некоторых пор KiCad предоставляет возможность автоматизации работы путём использования скриптов. Пока только в редакторе печатных плат, но всё же. Некоторое знакомство с этой темой показало следующее:

• запуск скрипта возможен только из специальной консоли;
• API документирован очень скудно, для нормальной работы явно недостаточно;
• примеров от разработчиков почти нет, всё, что можно найти, это частный опыт отдельных энтузиастов;
• не ясно, можно ли применить скрипт не просто ко всей плате, а только к выделенным компонентам;
• не понятно, как сделать, чтобы изменения внесённые работой скрипта, сразу отображались на плате (приходится режим Canvas переключать руками).

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

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

И вот захотелось мне поменять размер шрифта текстовых полей посадочных, накопал скрипт на гитхабе, чуть-чуть его подрихтовал, чтобы запускалось... работает. Т.е. уменьшил размер шрифта, как и хотел. Но при этом пришлось править скрипт, а не задать размеры шрифта из редактора ПП, после отработки скрипта пришлось переключать режим Canvas, чтобы вид обновился. И даже после этого pcbnew не "врубился", что в плате есть изменения, т.е. он "считает", что плата не изменилась и поэтому сохранить файл в данный момент не даёт (пришлось подвигать посадочное, чтобы до него "дошло").

(Да, конкретно изменить размеры шрифта текстовых полей можно из из редактора ПП, но тут речь не об этом, а про принцип)

В то же время изменить размер текстовых полей можно в текстовом редакторе, который поддерживает регулярные выражения (например, в том же geany). И делается это куда проще и быстрее. Таким же образом можно менять что угодно, только заготовить соответствующие паттерны regex.

В общем, кто этим реально пользуется, поделитесь опытом. И вообще, что думаете про перспективы этой фичи?

[BackEnd]

Пользовался KiCad давно, могу высказать только самые общие соображения.

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

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

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

Проект живой, дышит, развивается. Дамаю, усё будет.

И вообще, что думаете про перспективы этой фичи?

Фича не мешающая работе и ничего не ломающая в уже существующем коде полезна по-любому. Пока пробный шар, потом народ подтянется. Можете сами к разработке подключиться или высказать пожелания команде.

[dxp]

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

Да, я не вполне корректно выразился. Имел в виду не столько редактирование в текстовом редакторе, сколько обработку файлов снаружи пакета, в первую очередь, конечно же, скриптами (текстовый редактор тут упомянут просто как самое простое средство). Собственно вопрос ставится: "Встроенные средства" vs "Внешние средства".

Что фича есть не просит, оно так. Но вопрос в том, стоит ли изучать, если вдруг она бесполезная.

[nill]

Собственно вопрос ставится: "Встроенные средства" vs "Внешние средства".

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

[dxp]

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

Время - так получилось. К сожалению, это не всегда возможно. Сторонние инструменты, конечно, заруливают некоторые ситуации, но хочется, чтобы сам инструмент предоставлял требуемую функциональность. Например, я бы предпочёл всё то, что предоставляет упомянутый в соседней теме менеджер компонентов редактора схем, иметь непосредственно в редакторе схем. Для этого всего-то было бы достаточно, если бы был простой plugin API, который позволял бы иметь доступ к компонентам схемы.

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

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

[nill]

Например, я бы предпочёл всё то, что предоставляет упомянутый в соседней теме менеджер компонентов редактора схем, иметь непосредственно в редакторе схем.

Получите, распишитесь :
https://lists.launchpad.net/kicad-developers/msg26723.html
К сожалению, у меня сейчас совсем нет времени для тестирование обоих вариантов и я не могу сказать, насколько они перекрываются в плане фукнций, но патч по ссылке встретили положительно, так что есть вероятность, что он будет добавлен в основной код. Собственно, сам патч в той же рассылке:
https://lists.launchpad.net/kicad-developers/msg26742.html

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

С этим полностью согласен. Не могли бы Вы отписаться о впечатлениях об использовании их системы плагинов после того, как получится её протестировать?

Сообщение отредактировал nill - Nov 24 2016, 07:26