Вывод текстовой документации в KiCAD-ГОСТ, Обсуждаем разрабатываемые варианты вывода документации Опции

[Aldan]

Вот уже на протяжении нескольких лет время от времени предпринимаются попытки прикрутить к Кикаду вывод текстовой документации. Например, на Кикад-фтп в свое время была выложена альфа-утилитка (если мне не изменяет память), которая преобразовывала кикадовский ВОМ в некое подобие перечня элементов, который выводился в МсВорд. Помнится, я попробовал тогда ею воспользоваться и обнаружил, что утилита очень сырая, т. к. перечень получался с какими-то непонятными полосами и прочими недоработками. Но не беда, ведь это только начао — подумал я, ведь со временем все наладится. Но, надежды не оправдались, т. к. дальнейшего развития не произошло, да и необходимость иметь на компе платный МсВорд для бесплатного Кикада как-то тоже не радовало. Словом, все заглохло.
Параллельно этой утилите другим форумцем велась разработка своего варианта такой важной полезняшки. Он со временем даже демонстрировал скриншот Кикада с новой иконкой по нажатию на которую можно было активировать функцию вывода документации по ГОСТ. Более того, однажды он написал на форуме, что до полного окончания работ осталась всего неделя, что привело меня в бурную радость.., однако, когда прошло больше года и я обескураженный решил спросить его на форуме когда же можно будет потестить разрабатываемую им мегафичу. К моему удивлению, он ответил, что давно забросил эту разработку т. к. не смог с какой-то тонкостью Кикада разобраться.
Я так и не понял тогда, зачем же он объявил всем, что практически все готово, т. к. неделя на вылизывание не в счет, В общем, опять все заглохло.
Конечно, работа ведется на энтузиазме в свое личное время, которого чаще всего не хватает и на более важные дела, поэтому нельзя ничего определенного ожидать. Но все же...
Прошло еще достаточно много времени и вот, на нашем форуме появляется желанное сообщение Барановского Константина:

Написал скрипт для создания спецификации, оформленной по требованиям ЕСКД, из BOM файла сгенерированного в EEschema (...)

Посмотрев на приаттаченный пример работы скрипта надежда на лучшее снова стала оживать, но опыт прежних неудач, когда тоже были продемонстрированы первые результаты, а потом пшик, заставлял приглушить радостные эмоции до момента тестирования готовой фичи, если, конечно, она будет реализована.
А дальше — больше, т. к. оказалось, что не только Константин занят разработкой вывода документации, но еще и AVL:

Константин, приветствую. Я в замешательстве Недели 2 назад начал разработку генератора перечня элементов и спецификации (в соответствии с ГОСТ) на c++ как дополнительный инструмент в самом KiCad с поддержкой исполнений. Вы меня опередили Теперь и не знаю как быть, продолжать свой делать или остановиться

К тому же, возможно, они объединят свои усилия:

AVL, здравствуйте! Думаю нужно продолжать. Нативный генератор перечня куда лучше скрипта, к тому же одно другому не мешает. В случае чего, готов помочь.

Но идет время и пока тишина... Неужели опять все напрасно? Хочется верить, что нет. Просто как всегда не хватает времени и еще все будет. Просто еще не время.
Как бы то ни было, я решил открыть эту тему для того, чтобы на ее страницах можно было обсуждать эту долгожданную мегафичу — вывод текстовой документации в Кикаде.

[AVL]

В принципе уже все ясно с настроем админов проекта. Беспредел одним словом, который длится без конца.

Переименовал ветку lp:~al-lunev/kicad/GOST-doc-gen в lp:~kicad-gost-committers/kicad/kicad,
а ветку lp:~pcad2kicad-committers/kicad/pcad2kicad в lp:~kicad-gost-committers/kicad/pcad2kicad

Добавил в нее участников среди русскоязычных разработчиков.
Если кто-то не хочет быть участником среди добавленных, дайте знать.

Все кто в этом списке, у вас есть доступ на запись в https://code.launchpad.net/~kicad-gost-comm...ers/kicad/kicad

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

Данную ветку рассматриваю альтернативной ветке lp:kicad.
Предлагаю давать возможность работать в ветке lp:~kicad-gost-committers/kicad/kicad по возможности всем желающим, не только ГОСТ-разработчикам.

Планирую ветку lp:~kicad-gost-committers/kicad/pcad2kicad смержить с lp:~kicad-gost-committers/kicad/kicad

Если есть замечания / пожелания, пишите.

[Сергей Борщ]

Данную ветку рассматриваю альтернативной ветке lp:kicad.

Правильно ли я понимаю, что из исходников этой ветки можно будет также собрать полноценный вариант с не-ГОСТ рамкой? И что теперь уже в нее будут периодически вливаться изменения основной ветки, а не наоборот? То есть в нее можно спокойно добавлять улучшения не связанные именно с ГОСТ-документацией?

[AVL]

Правильно ли я понимаю, что из исходников этой ветки можно будет также собрать полноценный вариант с не-ГОСТ рамкой? И что теперь уже в нее будут периодически вливаться изменения основной ветки, а не наоборот? То есть в нее можно спокойно добавлять улучшения не связанные именно с ГОСТ-документацией?

Да, так.
Насчет ГОСТ рамки предлагаю сделать так, чтобы можно было выбирать вид рамки прямо из меню программы в настройках.

Единственное, может есть смысл все-таки оставить конструкции #ifdef KICAD_GOST #endif с целью сохранить некую границу между lp:kicad и lp:~kicad-gost-committers/kicad/kicad. Это, с моей точки зрения, облегчит работу при слияниях.

Не исключаю, что часть исходников все-таки будет вливаться из lp:~kicad-gost-committers/kicad/kicad обратно в lp:kicad.
Данное действие сможет делать самостоятельно Андрей Федорушков, если нет для этого препятствий. Судя по настрою админов, чувствую препятствия есть. И я пока не знаю мнение Андрея.
Также данное действие смогут делать админы lp:kicad, если вдруг снизойдут до этого.

Если вы поддерживаете сохранить конструкции #ifdef KICAD_GOST #endif, то изменения не касающиеся ГОСТ также предлагаю помещать в эти конструкции. Поскольку любые изменения, не только ГОСТ, сложно протолкнуть в lp:kicad. А конструкция #ifdef KICAD_GOST #endif, как я уже сказал, с моей точки зрения, облегчит нам работу по слиянию. И скорее всего облегчит работу тем, кто будет вливать изменения в lp:kicad.

Поскольку предлагаю помещать любые изменения в #ifdef KICAD_GOST #endif, при условии, что вы согласны и считаете это правильным, возможно имеет смысл переименовать эти дефайны в какое-то более универсальное имя вместо KICAD_GOST.

[Сергей Борщ]

Насчет ГОСТ рамки предлагаю сделать так, чтобы можно было выбирать вид рамки прямо из меню программы в настройках.

Очень давно хочется такую возможность. Приходится работать с обоими вариантами и переключать их копированием разных сборок в папку запуска несколько неудобно. Также нужно, чтобы выбор рамки сохранялся в файле платы. Наверное для совместимости лучше сделать сохранение в файле метки"ГОСТ-рамка", а при ее отсутствии включать буржуйскую. Тогда файл с буржуйской рамкой не будет содержать непонятных для основной версии записей.

Единственное, может есть смысл все-таки оставить конструкции #ifdef KICAD_GOST #endif с целью сохранить некую границу между lp:kicad и lp:~kicad-gost-committers/kicad/pcad2kicad. Это, с моей точки зрения, облегчит работу при слияниях.

Да, если этот #define не будет привязан к рамке, то под него можно будет помещать и код, используемый и с другой рамкой.

[AVL]

Очень давно хочется такую возможность. Приходится работать с обоими вариантами и переключать их копированием разных сборок в папку запуска несколько неудобно. Также нужно, чтобы выбор рамки сохранялся в файле платы. Наверное для совместимости лучше сделать сохранение в файле метки"ГОСТ-рамка", а при ее отсутствии включать буржуйскую. Тогда файл с буржуйской рамкой не будет содержать непонятных для основной версии записей.
Да, если этот #define не будет привязан к рамке, то под него можно будет помещать и код, используемый и с другой рамкой.

Мне в личном письме Жан-Пьер написал такое, что существенно меняет картину по поддержке ГОСТ.
Я ему "порекомендовал" описать их намерения и видение по этому поводу публично на developer mailing list.
Данные намерения ожидаются в пользу ГОСТ. Как будет на самом деле, посмотрим.