Перейти к содержанию
    

Всем привет!

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Боюсь, долго ждать придётся. Уж года три как анонсировано, если ничего не путаю, но пока выглядит как будто начальный этап.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

http://docs.kicad-pcb.org/master/en/plugins.html

 

Примеров, конечно, маловато, но начало положено.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

http://docs.kicad-pcb.org/master/en/plugins.html

 

Примеров, конечно, маловато, но начало положено.

О! Не знал про это. Будем смотреть, спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Получите, распишитесь :) :

https://lists.launchpad.net/kicad-developers/msg26723.html

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

https://lists.launchpad.net/kicad-developers/msg26742.html

 

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

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

Изменено пользователем nill

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Получите, распишитесь :) :

https://lists.launchpad.net/kicad-developers/msg26723.html

К сожалению, это не совсем то, о чём шла речь. Это не плагин, а добавление функциональности в основной код пакета. И вот это главное. Ведь будь это реально плагином, то есть отдельно и независимо компилируемым модулем, это можно было бы просто докинуть в директорию plugings установленного пакета и всё. Для этого не требуется ни рассмотрение командой разработчиков, ни их одобрение. Кто захотел, тот себе докинул и пользуется. Собственно, скриптование ведь именно этот подход и проповедует и этим привлекательно. Насколько могу судить, изрядным препятствием для многих полезных и нужных фич является внутренняя позиция главных разработчиков пакета. Порой просто необъяснимое упорство и волюнтаризм. Ветка kicad-gost ведь неспроста появилась.

 

Система плагинов (в моём понимании, но это то, как оно реализовано во многих успешных программах) базируется на двух столпах:

  • полная независимость сборки от основного source tree;
  • развитый и внятный API, позволяющий как интегрировать средства управления добавляемой функциональностью (добавить пункты меню, кнопки на тулбары, горячие клавиши), так и иметь (защищённый) доступ к внутренней базе данных по чтению и записи.

Технически это должно выглядеть примерно так (пусть для редактора схем). Ядро основной программы редактора схем предоставляет (экспортирует) набор функций типа add_menu(), add_menu_item(), add_toolbar(), add_toolbar_button(), add_shortcut() и т.д. для внедрения средств управления и второй набор: get_components(), get_selected_objects(), add_component_property(), set_component_property() и т.п.

 

Весь этот набор - прототипы функций - помещается в специальный заголовочный файл, предназначенный для разработчиков плагинов, который кладётся в проект плагина. Далее пишется код плагина, проект собирается, на выходе получается динамическая библиотека (so/dll), которою теперь достаточно просто скопировать в директорию plugins установленного пакета. При старте редактора схем тот ищёт в директории плагинов динамические библиотеки и подключает те, которые относятся к нему (для этого должен быть предусмотрен механизм хендшейка - загрузчик запрашивает у динамической библиотеки назначение и принимает решение, грузить её или нет, это несложно).

 

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

 

И второй не менее важный момент: всё это не требует вникать в потроха пакета - достаточно ознакомиться только с API, а он должен быть несложным и ориентированным на приложение, что сильно снижает порог вхождения, т.к. разработчик плагина - это пользователь пакета, т.е. человек, который плотно в теме предметной области.

 

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

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

 

В общем, оно больше похоже на частную попытку расширить функциональность пакета с помощью динамической библиотеки.

 

UPD. Будь такой (как описано выше) плагинный механизм в eeschema, я бы препринял попытку оформить упомянутый в соседней теме менеджер компонентов в виде плагина. А может и расширить функциональность - не только компоненты, но и остальные объекты схемы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По поводу Python Scripting. Попробовал кое-что, в целом работает.

 

Первым делом прикрутил согласно инструкции браузер-ланчер скриптов - чтобы не руками каждый раз вбивать, а одним кликом запускать.

 

Попробовал два скрипта от того же автора. Первый - изменение свойств текстовых полей (хотя в текущей версии pcbnew это не так актуально - есть такая функция вменю Edit).

 

Второй более полезный - позволяет рисовать keepout зоны круглой формы. Это нужно, например, вокруг крепёжных отверстий, а кикад не "умеет" зоны круглой формы делать. Сам скрипт. В конце я подредактировал под свой проект, добавил строки

 

insert_keepout_around_mod("MS1", 2.5, corners=32, layers=(pcbnew.F_Cu, pcbnew.B_Cu,))
insert_keepout_around_mod("MS2", 2.5, corners=32, layers=(pcbnew.F_Cu, pcbnew.B_Cu,))
insert_keepout_around_mod("MS3", 2.5, corners=32, layers=(pcbnew.F_Cu, pcbnew.B_Cu,))
insert_keepout_around_mod("MS4", 2.5, corners=32, layers=(pcbnew.F_Cu, pcbnew.B_Cu,))

 

где MS1..MS4 - это посадочные крепёжных отверстий. Выглядит вот так:

post-1343-1479989110_thumb.png

Keepout зоны добавлены во внешних сигнальных слоях.

 

После применения скрипта нужно переключить режим Canvas, иначе изменения не отображаются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По поводу Python Scripting. Попробовал кое-что, в целом работает.

 

Первым делом прикрутил согласно инструкции браузер-ланчер скриптов - чтобы не руками каждый раз вбивать, а одним кликом запускать.

 

Попробовал два скрипта от того же автора. Первый - изменение свойств текстовых полей (хотя в текущей версии pcbnew это не так актуально - есть такая функция вменю Edit).

 

Поясните как вы "прикрутили" первый скрипт

 

- я создал директорию где у меня будут храниться макросы

- в pcbnew в меню Preferences - Configure Paths dialog добавил переменную _KIMACROS и указал для нее путь к созданной выше директории

- дальше нужно куда-то вставить текст скрипта pyshell_hack.py и тут я уже потерялся куда вставлять и что делать

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я для себя начал было делать утилитку для копирования идентичных кусков, но как-то подзабил на это. Часть вещей можно делать при помощи sed и awk, благо формат текстовый. Но вот непосредственно что-то прикрутить так, чтобы прямо из кикада запускать — это фантастика, к сожалению! Увы, кикад написан на С++, а не С, и это печально…

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...