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

[Aldan]

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

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

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

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

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

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

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

[Барановский Конс...]

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

В своем сообщении о скрипте я писал:

Хотелось бы узнать ваше мнение и услышать конструктивные замечания и предложения.

после чего было получено только одно замечание от faa и далее тишина. Раз никто не жалуется и ничего не предлагает, то возможны два варианта:
1) все пользуются и все довольны;
2) никто не пользуется, никому не нужно.
Я думаю что в данном случае имеет место второй вариант и раз так, можно не спешить с нововведениями и улучшениями, так как не для кого стараться, а для меня хватает и реализованной функциональности.

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

[IgorKossak]

1) все пользуются и все довольны;
2) никто не пользуется, никому не нужно.

На опросник похоже. Так почему бы его не создать?
Я бы проголосовал "за".

[Leonid Egorov]

после чего было получено только одно замечание от faa и далее тишина.

Скрипт скачал, но еще не прикрутил. Поэтому замечаний нет Штука-то полезная.

[Aldan]

было получено только одно замечание от faa и далее тишина.

Константин, для того, чтобы можно было высказать свое мнение о работе Вашего скрипта, нужно попрактиковаться в выводе документации при помощи него, ведь так? А теперь посмотрим в на эту ситуацию глазами обычного пользователя Кикада, не программиста, каким являюсь я. Такой пользователь резонно ожидает такой готовности предлагаемого программного продукта, когда он будет органично интегрирован в Кикад, как все его составляющие. Например, при выводе перечня элементов будет достаточно поставить галочку в чекбоксе «выводить перечень в ГОСТ» и на выходе мы получим вместо абстрактной таблицы в Екселе именно то, что нам надо. Или, например, в менеджере Кикада к шести уже имеющимся кнопкам запуска приложений добавится седьмая - «текстовая документация». В любом случае речь идет о законченном приложении, интегрированном в существующий графический интерфейс и все это устанавливается без бубна совместно с установкой самого Кикада.
Ваше сообщение с анонсом своего скрипта я воспринял как обращение к программистам, могущим и «прикрутить» и в консоли поработать. Я же командной строкой пользовался за всю свою жизнь раз десять, да и скриптами с «костыликами» никогда не игрался. Таких как я, увы, много, возможно — большинство. Вот и молчит это большинство, т. к. еще не получило в свои руки сей важный инструмент, чтобы можно было его потестировать.
Тут уж Вам нужно определиться: либо вы делаете свой продукт только для «продвинутых» и тогда то, что уже реализовано можно считать достаточным, либо Вы делаете законченный продукт интегрированный в Кикад и тогда это будет «для всех». Хочется верить, что Вы настроены на доведение своей разработки до полной завершенности
В данный же момент мне даже не понятно поддерживает ли нынешняя версия Кикада python или нет. Ведь об этой поддержке уже многое писали, однако писали и о том, что вроде бы сейчас это отключено (я пишу о стаб. сборке 4009). Если поддерживает, то зачем Вы в своем readme требуете его установку, а также установку odfpy? Если пока не поддерживает, но может, так не лучше ли в ГОСТ версии таки реализовать эту поддержку, чтобы в довесок в Кикаду не устанавливать целый перечень доп. программ и потом разбираться в их взаимодействии вместо работы в САПРе? Почему нельзя сразу в общем пакете установить opengostfont, а нужно опять прыгать с бубном и как Вы пишете «может придется подобрать шрифт, желательно моноширинный»? А требуемая настройка шести пользовательских полей разве не может быть один раз на всю жизнь сделана при сборке Кикада? Ведь если кому-то не понравится, то он поля легко исправит?
Словом, я за то, чтобы все новые приложения по уровню безгеморройности и завершенности соответствовали самому Кикаду и вызывали радость, а не головную боль.
Но не зря существует поговорка: «сытый голодного не поймет». «Сытый» - продвинутый, самодостаточный, могущий «прикрутить», а «голодный» — тот, кто ожидает понимания и снисхождения, т. к. по сложившейся ситуации не владеет тем, чем владеет «сытый». Вот и проходят мимо «голодных» скрипты и «костылики на перловке», а могли бы украсить Кикад на радость всем, а не только продвинутым.
Чтобы не возникло вопросов типа, а сам-то чего не станешь «продвинутым», отвечаю. В этом году мен 59, а лет 6 — 7 назад я еще не умел самостоятельно устанавливать приложения и только-только сел за компьютер. Так уж сложилась жизнь, она у всех разная...
Простите за пространные речи, просто хочется, чтобы Вы могли понять реальное положение вещей, тогда будете несколько иначе мыслить. И не ждите шквала отзывов, а работайте на будущего пользователя, который обязательно появится, если Кикад станет дружественным и функциональным. Кстати, если замечали, все предлагаемые материалы обычно скачивают не более, чем полтора-два десятка человек, что говорит о том, что на форуме не так много «нашего брата».
И еще, пожелание: подумайте, может быть реализовать не только вывод перечня, но и ведомость покупных раз уж есть ВОМ, ведь тоже гостовский текстовый документ, причем гораздо более простой по организации.

[AVL]

Всем привет.

Как раз и разрабатываю интегрированный модуль для формирования документации по ГОСТ.
Скоро выложу ветку на launchpad.

[Aldan]

Как раз и разрабатываю интегрированный модуль для формирования документации по ГОСТ.

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

Скоро выложу ветку на launchpad.

Желаю успеха! Надеюсь, что финальный релиз Кикада в обозримом будущем будет пересобран для интеграции в него вывода текстовой документации по ГОСТ требованиям.

[viknn]

Вариант шаблона спецификации для LibreOffice (с боковым и нижним штампами)

Прикрепленные файлы

 sp.zip ( 21.44 килобайт ) Кол-во скачиваний: 141

 

[Барановский Конс...]

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


Также добавил справочное руководство, в котором старался как можно подробнее описать процесс установки и работы с программой. Но все же, если возникнут вопросы/предложения (любые), задавайте.

Архив с программой и руководством можно загрузить отсюда: https://launchpad.net/kicadbom2spec

P.S.

Константин, для того, чтобы можно было высказать свое мнение о работе Вашего скрипта, нужно попрактиковаться в выводе документации при помощи него, ведь так?

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

Тут уж Вам нужно определиться: либо вы делаете свой продукт только для «продвинутых» и тогда то, что уже реализовано можно считать достаточным, либо Вы делаете законченный продукт интегрированный в Кикад и тогда это будет «для всех»

К сожалению, на создание генератора спецификации интегрированного в KiCAD сейчас банально нет времени.

Сообщение отредактировал Барановский Константин - Apr 20 2013, 10:19

[viknn]

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

Прошел по маршруту kicadbom2spec в Windows XP, руководство подробное (спасибо Косте).
Вместо рабочего стола для установки odfpy использовал строку Total Commander - получилось.
Пожелание: включить в дистрибутив простой набор файлов sample.* для примера и демонстрации результата.
Можно будет попробовать сделать автоустановку всего через NSIS.

[AVL]

Всем привет.

Хотел узнать, есть ли где-либо (в bzr репозиториях, на ftp и т.д.) свободно распространяемый пример электрической принципиальной схемы (включая библиотеки) оформленной по ГОСТ для KiCad?

Хочу добавить такой пример в директорию demos дерева проекта KiCad по аналогии примерам не ГОСТ исполнения, которые находятся в директории demos. (Пока планирую вручную добавить нужные аттрибуты для компонентов такой схемы-примера).

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

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

Исходники выложил в ветке https://code.launchpad.net/~al-lunev/kicad/GOST-doc-gen
Однако пока отлаживал под Linux Debian Squeeze (под Windows скорее всего пока не соберется).

Предварительно сделал генерацию документов через нажатие Eeschema->Tools->GOST Tools.

После сборки из исходников, генерируется файл env.sh в директории eeschema
Данный файл пока приходится запускать перед запуском eeschema следующим образом:
. ./env.sh
иначе eeschema не увидит библиотеки программы Open Office.

Буду еще думать как убрать этот костыль.

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

[AVL]

Нарисовал пока свой пример схемы https://code.launchpad.net/~al-lunev/kicad/GOST-doc-gen:
demos/GOST/multivibrator.sch (путь в дереве кикада)

Компонентам назначены аттрибуты так, чтобы продемонстрировать формирование документов для схем с исполнениями.

[Aldan]

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

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

Исходники выложил в ветке (...) Однако пока отлаживал под Linux Debian Squeeze (под Windows скорее всего пока не соберется).

AVL, хочу и Вам пожелать удачи! Может быть к тому моменту, когда я закруглюсь с ремонтом и Ваш вариант вывода документации под Виндами будет готов. Вот ведь, еще недавно не было ничего на этом поприще, а теперь намечается изобилие
--------------------------
Еще раз прошу прощения за свою временную пассивность на форуме по причине своего жилищного форсмажора.

[IgorKossak]

Жаль, что на нашем аскетичном форуме, где ум преобладает над чувствами и не принята бурная реакция на предлагаемые новшества, Вы не получили многочисленной ответной реакции пользователей.

Действительно, жаль. Был бы хоть какой-нибудь "лайк", я бы поставил.
На одной консультируемой мною фирме последней каплей среди аргументов перехода на KiCAD послужило наличие вывода гостовской документации.

[Барановский Конс...]

Исходники выложил в ветке https://code.launchpad.net/~al-lunev/kicad/GOST-doc-gen
Однако пока отлаживал под Linux Debian Squeeze (под Windows скорее всего пока не соберется).
...
Для возможности сборки проекта из исходников, понадобится установить Open Office SDK.

Хотел попробовать, но в Ubuntu OpenOffice SDK просто так не установишь, а LibreOffice SDK не подходит. Если есть возможность, выложите собранные бинарники KiCAD, уж очень интересно что да как.

[AVL]

Хотел попробовать, но в Ubuntu OpenOffice SDK просто так не установишь, а LibreOffice SDK не подходит. Если есть возможность, выложите собранные бинарники KiCAD, уж очень интересно что да как.

Константин, а у Вас какая версия Ubuntu (включая архитектуру)?

[Барановский Конс...]

AVL, Ubuntu 13.04 32 bit.

P.S. лучше на "ты"

[AVL]

AVL, Ubuntu 13.04 32 bit.

P.S. лучше на "ты"

Официальный релиз Ubuntu 13.04 вроде бы завтра выходит. По крайней мере сейчас я не нашел где официально можно скачать Ubuntu 13.04.
Константин, у тебя есть ссылка, где можно скачать Ubuntu 13.04?

[Барановский Конс...]

Да, официальный релиз должен появиться завтра, но я не смог удержаться и еще месяц назад перешел на тестовую версию, т.к. все говорили о высокой стабильности. Ежедневные сборки доступны здесь: http://cdimage.ubuntu.com/daily-live/current/.

[viknn]

Приведу два ГОСТа на текстовые КД:
ГОСТ 2.701-2008 - ЕСКД. Схемы. Виды и типы. Общие требования к выполнению. Здесь раздел 5.7 посвящен
перечню элементов (ПЭ), который "помещают на первом листе схемы или выполняют в виде самостоятельного документа".
ПЭ выполняют в виде таблицы заданной формы. Даны правила заполнения.

ГОСТ 2.106-96 (переиздание 2007 года) - ЕСКД. Текстовые документы (в том числе спецификация, СП).
В СП восемь разделов. В пункте 3.7 описывается заполнение самого трудоемкого раздела "Прочие изделия",
куда и заносятся компоненты ЭРИ для печатных плат. Приведены формы документов.

Сообщение отредактировал viknn - Apr 24 2013, 16:01

Прикрепленные файлы

 gost_eskd_2.701_2008.pdf ( 294 килобайт ) Кол-во скачиваний: 111
 gost_eskd_2.106_96__2007_.pdf ( 1.27 мегабайт ) Кол-во скачиваний: 85

 

[AVL]

Хотел попробовать, но в Ubuntu OpenOffice SDK просто так не установишь, а LibreOffice SDK не подходит. Если есть возможность, выложите собранные бинарники KiCAD, уж очень интересно что да как.

Добавил поддержку LibreOffice, а также новых версий OpenOffice/LibreOffice (начиная с версии 3.4 разработчики OpenOffice/LibreOffice изменили способ соединения с офисом).

Отлаживал под Ubuntu 13.04 32-bit (официальный релиз), установленной под VirtualBox.

Код

sudo apt-get install bzr cmake g++ freeglut3-dev libwxgtk2.8-dev libreoffice-dev
bzr branch lp:~al-lunev/kicad/GOST-doc-gen
cd GOST-doc-gen
mkdir Release
cd Release
cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON
. eeschema/env.sh
make
sudo make install
eeschema/eeschema

Сейчас есть две проблемы:
1) приходится до команды make запускать ". eeschema/env.sh", чтобы в переменную окружения LD_LIBRARY_PATH прописался путь к библиотекам URE
2) приходится до запуска eeschema также запускать ". eeschema/env.sh" по тем же причинам (в текущей сессии достаточно запустить только один раз)

Константин, есть какие-нибудь идеи как решить пункт 1, чтобы не приходилось руками выполнять эту команду? Вчера для этого экспериментировал с cmake, пока не удалось победить.

Насчет пункта 2 у меня пока только идея - это добавить возможность в каком-нибудь окошке в кикаде конфигурировать путь к OpenOffice / LibreOffice.

[AVL]

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

Также добавил справочное руководство, в котором старался как можно подробнее описать процесс установки и работы с программой. Но все же, если возникнут вопросы/предложения (любые), задавайте.

Архив с программой и руководством можно загрузить отсюда: https://launchpad.net/kicadbom2spec

Решил попробовать данный скрипт. Установил odfpy 0.9.6.
При запуске скрипта потребовало пакеты (у меня Linux Debian 6.0.7) - установил:
sudo apt-get install python-argparse
sudo apt-get install python-tk

Далее при запуске скрипта вываливается ошибка:

Код

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1413, in __call__
    return self.func(*args)
  File "./kicadbom2spec.pyw", line 561, in specMake
    spec.loadBOM(self.bomFileName.get())
  File "./kicadbom2spec.pyw", line 262, in loadBOM
    group[1].sort(key=self.compareRef)

Заархивированный тестовый файл прикрепил.

Прикрепленные файлы

 test.csv.zip ( 227 байт ) Кол-во скачиваний: 51

 

[Барановский Конс...]

... при запуске скрипта вываливается ошибка ...

Спасибо большое за описание ошибки! Приложил исправленный скрипт.

Прости, но последнее время был очень занят и не мог заняться решением проблем gost_doc_gen. Обязательно что-нибудь придумаем

P.S.
В BOM файле, в поле Field 5 должна указываться точность, а примечание в поле Field 6.

Сообщение отредактировал Барановский Константин - Apr 29 2013, 19:26

Прикрепленные файлы

 kicadbom2spec.pyw.zip ( 6.52 килобайт ) Кол-во скачиваний: 51

 

[AVL]

Спасибо большое за описание ошибки! Приложил исправленный скрипт.

Спасибо. Теперь заработало.

Впечатление положительное, что нет проблем с всякими коннектами / путями к OpenOffice/LibreOffice.
Я уже стал задумываться, может как-то odfpy прикрутить к GOST-doc-gen, либо может есть c++ odfpy-альтернатива.

[Барановский Конс...]

AVL, GOST_doc_gen не хочет собираться:

Код

[ 72%] Building CXX object eeschema/CMakeFiles/eeschema.dir/__/common/base_units.cpp.o
Linking CXX executable eeschema
/usr/bin/ld: не вдалося знайти -luno_cppuhelpergcc3
/usr/bin/ld: не вдалося знайти -luno_cppu
/usr/bin/ld: не вдалося знайти -luno_salhelpergcc3
/usr/bin/ld: не вдалося знайти -luno_sal
collect2: ошибка: выполнение ld завершилось с кодом возврата 1
make[2]: *** [eeschema/eeschema] Ошибка 1
make[1]: *** [eeschema/CMakeFiles/eeschema.dir/all] Ошибка 2
make: *** [all] Ошибка 2
baranovskiykonstantin@Lenovo-G550:~/src/kicad.GOST_doc_gen/Release$ cd $LD_LIBRARY_PATH
baranovskiykonstantin@Lenovo-G550:/usr/lib/libreoffice/ure-link/lib$ ls
acceptor.uno.so       libjava_uno.so                 libuno_salhelpergcc3.so.3
binaryurp.uno.so      libjpipe.so                    libuno_sal.so.3
bootstrap.uno.so      libjuh.so                      libunsafe_uno_uno.so
connector.uno.so      libjuhx.so                     libxmlreader.so
introspection.uno.so  libjvmaccessgcc3.so.3          namingservice.uno.so
invocadapt.uno.so     libjvmfwk.so.3                 proxyfac.uno.so
invocation.uno.so     liblog_uno_uno.so              reflection.uno.so
javaloader.uno.so     libreg.so.3                    stocservices.uno.so
javavm.uno.so         libsal_textenc.so              streams.uno.so
JREProperties.class   libstore.so.3                  textinstream.uno.so
jvmfwk3rc             libsunjavaplugin.so            textoutstream.uno.so
libaffine_uno_uno.so  libuno_cppuhelpergcc3.so.3     unorc
libgcc3_uno.so        libuno_cppu.so.3               uuresolver.uno.so
libjava_uno           libuno_purpenvhelpergcc3.so.3

Вроде бы библиотеки на месте, но никак...

[viknn]

Впечатление положительное, что нет проблем с всякими коннектами / путями к OpenOffice/LibreOffice.

Получается, что если в C++/Qt-библиотеке (> 4.5) есть простые средства формирования ODF-файлов, то в C++/Wx их нет...

здесь кросс-платформенная свободная Qt-утилита kicad_service, © 2010, Павлюков.
написана для просмотра схем kicad (PDF формат kicad еще не поддерживал)
можно подключать ttf-шрифты типа opengostfont
попытка формировать BOM и перечень элементов (формат PS)

Сообщение отредактировал viknn - Apr 30 2013, 16:51

Прикрепленные файлы

 kicad_service_src.zip ( 796.41 килобайт ) Кол-во скачиваний: 50

 

[AVL]

AVL, GOST_doc_gen не хочет собираться:

Код

[ 72%] Building CXX object eeschema/CMakeFiles/eeschema.dir/__/common/base_units.cpp.o
Linking CXX executable eeschema
/usr/bin/ld: не вдалося знайти -luno_cppuhelpergcc3
/usr/bin/ld: не вдалося знайти -luno_cppu
/usr/bin/ld: не вдалося знайти -luno_salhelpergcc3
/usr/bin/ld: не вдалося знайти -luno_sal
collect2: ошибка: выполнение ld завершилось с кодом возврата 1
make[2]: *** [eeschema/eeschema] Ошибка 1
make[1]: *** [eeschema/CMakeFiles/eeschema.dir/all] Ошибка 2
make: *** [all] Ошибка 2
baranovskiykonstantin@Lenovo-G550:~/src/kicad.GOST_doc_gen/Release$ cd $LD_LIBRARY_PATH
baranovskiykonstantin@Lenovo-G550:/usr/lib/libreoffice/ure-link/lib$ ls
acceptor.uno.so       libjava_uno.so                 libuno_salhelpergcc3.so.3
binaryurp.uno.so      libjpipe.so                    libuno_sal.so.3
bootstrap.uno.so      libjuh.so                      libunsafe_uno_uno.so
connector.uno.so      libjuhx.so                     libxmlreader.so
introspection.uno.so  libjvmaccessgcc3.so.3          namingservice.uno.so
invocadapt.uno.so     libjvmfwk.so.3                 proxyfac.uno.so
invocation.uno.so     liblog_uno_uno.so              reflection.uno.so
javaloader.uno.so     libreg.so.3                    stocservices.uno.so
javavm.uno.so         libsal_textenc.so              streams.uno.so
JREProperties.class   libstore.so.3                  textinstream.uno.so
jvmfwk3rc             libsunjavaplugin.so            textoutstream.uno.so
libaffine_uno_uno.so  libuno_cppuhelpergcc3.so.3     unorc
libgcc3_uno.so        libuno_cppu.so.3               uuresolver.uno.so
libjava_uno           libuno_purpenvhelpergcc3.so.3

Вроде бы библиотеки на месте, но никак...

Линкер не видит файлы so.3. Ему нужны файлы so.
На этапе линковки линкеру передается путь ${OOO_SDK_DIR}/lib (для ubuntu 13.04 32-bit этот путь = /usr/lib/libreoffice/sdk/lib). Там и лежат файлы so (симлинки на so.3, которые, в свою очередь, лежат в /usr/lib/libreoffice/ure-link/lib)

Раз линкер не может найти указанные библиотеки, значит по какой-то причине cmake не смог вычислить корректно значение переменной OOO_SDK_DIR (это вычисление выполняет модуль GOST-doc-gen/CMakeModules/FindOpenOffice.cmake, то есть на него возлагаются надежды, что он на произвольной машине найдет корректно расположение офиса и его SDK).

Поэтому нужны логи выполнения команды cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON | tail -n15
И логи команды ls -la /usr/lib/libreoffice/sdk/lib

P.S.
LD_LIBRARY_PATH тоже должен быть проинициализирован (в данном случае = /usr/lib/libreoffice/ure-link/lib, судя по приложенным логам, проинициализирован верно), иначе не будут найдены зависимости, необходимые библиотекам uno_cppuhelpergcc3, uno_cppu, uno_salhelpergcc3, uno_sal.

Получается, что если в C++/Qt-библиотеке (> 4.5) есть простые средства формирования ODF-файлов, то в C++/Wx их нет...

Жаль, что KiCad не на базе Qt

Прикручивать Qt только, чтобы формировать odf - избыточно, хотя тоже вариант.

Значит имеем 3 варианта:
1) оставить все как есть (OO SDK). В случае с Windows пытаюсь добиться компиляции KiCad с помощью VC Express 2010 (с помощью VC Toolkit 2003 уже не получается собрать wxWidgets, поскольку в составе VC Toolkit 2003 нет nmake.exe). Если удастся собрать сам KiCad, то появляется возможность слинковать OO SDK. Жаль, что библиотеки OO SDK не собирают для mingw, и очень странно, что они есть только для VC.
2) прикручивать odfpy
3) прикручивать qt

[Барановский Конс...]

нужны логи выполнения команды cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON | tail -n15
И логи команды ls -la /usr/lib/libreoffice/sdk/lib

Код

baranovskiykonstantin@Lenovo-G550:~/src/kicad.GOST_doc_gen/Release$ cmake -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON ../ | tail -n15
Build stable version of KiCad
-- Looking for gettimeofday
-- Looking for gettimeofday - found
-- Looking for getc_unlocked
-- Looking for getc_unlocked - found
-- Bazaar version control system version  found.
-- Kicad Bazaar build version: (2013-04-28 BZR 4097 GOST)
-- Found OpenOffice.org SDK: /usr/lib/libreoffice/sdk
-- Found OpenOffice.org program directory: /usr/lib/libreoffice/program
-- Found unopkg executable: /usr/lib/libreoffice/program/unopkg
-- Found URE Java path: /usr/lib/libreoffice/ure-link/share/java
-- Found OpenOffice.org SDK include directory: /usr/lib/libreoffice/sdk/include
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.3.1")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/baranovskiykonstantin/src/kicad.GOST_doc_gen/Release
baranovskiykonstantin@Lenovo-G550:~/src/kicad.GOST_doc_gen/Release$ ls -la /usr/lib/libreoffice/sdk/lib
итого 16
drwxr-xr-x 2 root root 4096 Апр 24 10:53 .
drwxr-xr-x 6 root root 4096 Апр 24 10:53 ..
-rw-r--r-- 1 root root 4234 Апр 11 21:44 libsalcpprt.a
lrwxrwxrwx 1 root root   45 Апр 11 21:22 libuno_cppuhelpergcc3.so -> ../../ure-link/lib/libuno_cppuhelpergcc3.so.3
lrwxrwxrwx 1 root root   35 Апр 11 21:22 libuno_cppu.so -> ../../ure-link/lib/libuno_cppu.so.3
lrwxrwxrwx 1 root root   48 Апр 11 21:22 libuno_purpenvhelpergcc3.so -> ../../ure-link/lib/libuno_purpenvhelpergcc3.so.3
lrwxrwxrwx 1 root root   44 Апр 11 21:22 libuno_salhelpergcc3.so -> ../../ure-link/lib/libuno_salhelpergcc3.so.3
lrwxrwxrwx 1 root root   34 Апр 11 21:22 libuno_sal.so -> ../../ure-link/lib/libuno_sal.so.3

[AVL]

Константин, проверь, пожалуйста, новый коммит (4098) с исправлением. По идее должно заработать.

[Барановский Конс...]

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

[Барановский Конс...]

Немного обновил свой скрипт, изменений немного:

- добавил файлы для примера создания спецификации, описанного в руководстве;

Пожелание: включить в дистрибутив простой набор файлов sample.* для примера и демонстрации результата.

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

Решил попробовать данный скрипт. Установил odfpy 0.9.6.
...
Далее при запуске скрипта вываливается ошибка
...

Ну собственно и все. Скачать обновленный релиз можно отсюда https://launchpad.net/kicadbom2spec

[AVL]

Текущее состояние по GOST-doc-gen:
1) удается откомпилировать штатные исходники KiCad под винду только с помощью MinGW (перепробовал MS Visual C++ Toolkit 2003, MS Visual C++ 2008/2010 Express, ничем из перечисленного не удается откопмпилировать без ошибок)
2) с другой стороны OpenOffice/LibreOffice SDK поставляется с библиотеками под винду, которые можно линковать только с помощью MS Visual C++.
Таким образом, данный путь тупиковый. Единственное, что можно сделать - написать промежуточный проект-интерфейс (dll), соединяющий KiCad+GOST-doc-gen с OpenOffice SDK. Такой проект собирать с помощью MS Visual C++. Вариант не особо удобный.

Также размышлял насчет odfpy.

В результате решил добавить в GOST-doc-gen унифицированный интерфейс (класс COMMON_DOC_IFACE) для подключения различных модулей, реализующих какой-либо из способов подключения к офису, либо прямую генерацию файлов документов (например odfpy).

Весь специфический код по работе с OpenOffice/LibreOffice SDK вынес в отдельный модуль (класс OO_IFACE).

Дальше написал новый модуль с поддержкой odfpy (класс ODFPY_IFACE).
По odfpy вылезли следующие проблемы:
1) если открыть файл .odt и сразу же его без изменений сохранить, то в результирующем .odt файле "плывет" высота строк таблицы (то есть это баг odfpy).
2) оказалось, что odfpy поддерживает только абсолютную адресацию, которая полностью несовместима с именованной адресацией, используемой в GOST-doc-gen (вычислить одно из другого не возможно). В результате odfpy выбивается из построенной концепции унифицированного интерфейса (COMMON_DOC_IFACE).
По причине указанных проблем, пока принял решение отказаться от использования odfpy. По этой же причине исходники интеграции с odfpy пока не заливал.

В итоге набрел на еще один способ подключения к OpenOffice - использование Python-UNO.
И написал еще один модуль с поддержкой Python-UNO (класс OO_PYTHON_UNO_IFACE).

Отлаживался под Linux Debian 6.0.7. По крайней мере под Linux заработало. При использовании такого подхода (Python-UNO) ушли сложности с линкованием библиотек OO SDK.
Под винду еще не проверял, но по крайней мере линковать нелинкуемое уже не придется.

На данный момент предусмотрены следующие варианты сборки KiCad+GOST-doc-gen:
1) cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON - собирать KiCad с генератором документов как таковым. При этом генератор будет работать на базе Python-UNO (без OO SDK)
2) cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON -DUSE_OPENOFFICE_SDK=ON - вместо Python-UNO будет использоваться OO SDK

Пока думаю, что новый вариант сборки на базе Python-UNO (вариант номер 1) предпочтительнее.

[Барановский Конс...]

AVL, в Ubuntu не хочет собираться (используя Python-UNO). Лог в приложении.

Прикрепленные файлы

 build_log.txt ( 59.48 килобайт ) Кол-во скачиваний: 150

 

[viknn]

Пока думаю, что новый вариант сборки на базе Python-UNO (вариант номер 1) предпочтительнее.

Попробовал собрать под Windows. Cкомпилировалось без ошибок, но не собралось (путаница с версией python 2.7/2.6). Скриншоты начала и конца прилагаю.

Эскизы прикрепленных изображений

 

[AVL]

AVL, в Ubuntu не хочет собираться (используя Python-UNO). Лог в приложении.

Константин, исправил в ревизии 4105.

Ubuntu 13.04 32-bit:

Код

sudo apt-get install bzr cmake g++ freeglut3-dev libwxgtk2.8-dev python-dev python-uno
bzr branch lp:~al-lunev/kicad/GOST-doc-gen
cd GOST-doc-gen
mkdir Release
cd Release
cmake ../. -DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON
make
sudo make install

Пакет libreoffice-dev при такой конфигурации (сборка на базе Python-UNO без использования OO/LO SDK) устанавливать больше нет необходимости, но зато теперь нужны пакеты python-dev и python-uno (python-uno потребовался в случае ubuntu, я у себя на debian не ставил такой пакет).

Попробовал собрать под Windows. Cкомпилировалось без ошибок, но не собралось (путаница с версией python 2.7/2.6). Скриншоты начала и конца прилагаю.

Юрий, данную проблему исправил в ревизии 4105.
Под винду я еще недоотлаживал (в процессе). Там еще скорее всего сейчас вопросы выплывут.

[viknn]

Под винду я еще недоотлаживал (в процессе). Там еще скорее всего сейчас вопросы выплывут.

Application: Eeschema
Version: (2013-05-05 BZR 4105 GOST)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW

Сейчас все собралось до конца. Ошибка возникает по команде GOST Tools. Похоже не может запустить OpenOffice.
У меня XP и каталог программ - Program Files.

Эскизы прикрепленных изображений

 

[AVL]

Application: Eeschema
Version: (2013-05-05 BZR 4105 GOST)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW

Сейчас все собралось до конца. Ошибка возникает по команде GOST Tools. Похоже не может запустить OpenOffice.
У меня XP и каталог программ - Program Files.

Да, сейчас под винду в KiCad пока захаркодил строку к офису: C:\\Program Files (x86)\\OpenOffice.org 3\\program\\soffice.exe
Пока это можно обойти введя в командной строке: soffice "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"
Если напишет ошибку "soffice не является внутренней или внешней командой, исполняемой программой или пакетным файлом", то ввести полный путь, например:
C:\Program Files (x86)\OpenOffice.org 3\program\soffice.exe "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"
при этом путь к soffice.exe указать фактический какой есть на установленной системе.
В данном случае KiCad все равно будет выдавать ошибку "unable to launch the process: ...soffice.exe", но выполнение пойдет дальше. Сделал так, чтобы в случае, если не удается из KiCad по какой-то причине запустить офис в режиме listening, то хотя бы дать возможность пользователю выполнить эту команду из ОС.

Не могу понять где в винде путь к офису прописывается. Если выполняю команду soffice из cmd.exe, то не находит что такое soffice.
Если же запускаю из far.exe, то находит soffice и запускает нормально.
Если выполняю команду soffice из KiCad, то тоже не видит, что такое soffice. При этом добавление в %PATH% не помогает в случае с KiCad.

...но дальше еще появится ошибка, что не может найти uno. Тоже пытаюсь понять, что сделать.

[Барановский Конс...]

Снова ошибка:

Код

-- Configuring done
CMake Error at eeschema/GOST-doc-gen/CMakeLists.txt:92 (add_library):
  Cannot find source file:

    ../template_fieldnames_keywords.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

[AVL]

Снова ошибка:

Код

-- Configuring done
CMake Error at eeschema/GOST-doc-gen/CMakeLists.txt:92 (add_library):
  Cannot find source file:

    ../template_fieldnames_keywords.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

Исправил в ревизии 4106.

[AVL]

Наконец-то заработало под винду. Единственное пока пришлось написать bat файл, в котором настраиваются пути к питону. В линуксе (debian, ubuntu) такой кривости нет.

1) нужно установить Python 2.6.6 (именно эту версию, http://www.python.org/ftp/python/2.6.6/python-2.6.6.msi). Если есть еще какие-то установленные версии питона, то их нужно либо деинсталлировать, либо переименовать временно директорию, чтобы cmake при сборке по ошибке не стал использовать какую-нибудь другую версию питона отличную от 2.6.6.

2) нужно установить OpenOffice 3.4.1 (именно эту версию).

3) нужно обновиться с lp:~al-lunev/kicad/GOST-doc-gen (на данный момент ревизия 4107).

4) выполнить сборку с опциями: -DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON
После сборки Python 2.6.6 в момент исполнения уже не потребуется кикаду. KiCad будет подгружать интерпретатор питона из офиса (все версии офиса распространяются вместе с питоном, который находится в директории офиса). Но и мешать никакой отдельно установленный питон не должен на этапе исполнения кикада.

5) установить собранный KiCad

6) отредактировать пути в файле KiCad-GOST-doc-gen.bat (путь к офису и путь к кикаду, см. вложение к сообщению) согласно путям к установленным программам на вашей машине

7) запустить KiCad-GOST-doc-gen.bat

При запуске KiCad-GOST-doc-gen.bat настраиваются пути к питону офиса; запускается офис в режиме listening (пока убрал запуск из самого кикада и перенес этот запуск в KiCad-GOST-doc-gen.bat, чтобы не вываливалась ошибка в кикаде на захаркоденый путь к офису); запускается кикад

----------------

Итог. В случае с виндой ситуация при применении Python-UNO стала лучше (хоть собирается теперь проект), но не идеальная.
При таком подходе есть зависимость между сборкой KiCad и версией OpenOffice / LibreOffice.
К примеру, если собрать KiCad по описанному алгоритму на базе Python 2.6.6, то KiCad будет работать только с OpenOffice 3.4.1 (ну и может еще некоторые версии офиса), в составе которого идет Python 2.6.6.
Если будем запускать к примеру LibreOffice 4.0.2, в составе которого идет Python 3.3.0 (и uno библиотеки собранные для именно этой версии Python 3.3.0), то сборка KiCad сделанная для Python 2.6.6 не будет работать с LibreOffice 4.0.2.

В принципе ситуация достаточно стандартная с большинством программного обеспечения и их зависимостями как для винды, так и для Linux. В данном случае KiCad основая программа, а офис - его зависимость.
Но в плане реального пользования, конечно, бы хотелось собрать KiCad (сделать некий релиз), а дальше запускать произвольную версию офиса и чтобы все работало. То есть не навязывать пользователю какую версию офиса ему устанавливать. Тем более, что офис еще используется и для других целей, и используемая версия офиса может быть выбрана пользователем иной из каких-то других соображений, например пользователь установил самую новую версию офиса, потому что там есть важная новая функция.

Так вот, какое у вас мнение? Можно с этим мириться или все-таки необходимо уйти от версионной зависимости?

На этот счет у меня есть новая идея X: запускать модуль uno_iface.py не из встраиваемого в KiCad Python-интерпретатора как сделано сейчас, а вместо этого запускать модуль uno_iface.py в питоне, идущем в поставке вместе с офисом. При этом превратить модуль uno_iface.py в сервер для KiCadа. То есть сделать следующую цепочку:
KiCad+GOST-doc-gen -> [uno_server.py -> office]
Взаимодействие между KiCad и uno_server.py сделать через TCP соединение.

При такой схеме тогда не должно быть никакой версионной зависимости.

Прикрепленные файлы

 KiCad_GOST_doc_gen.zip ( 500 байт ) Кол-во скачиваний: 54

 

[Барановский Конс...]

Думаю все таки стоит избавиться от зависимости.

[viknn]

Прошел по маршруту kicadbom2spec в Windows XP, руководство подробное (спасибо Косте).
Можно будет попробовать сделать автоустановку всего через NSIS.

На ftp://ftp.kicad.ru/pub/kicad/kicad_eskd_d...ky_kicadbom2sp/
положил py-срипт К.Барановского для производства спецификации kicad на шаблоне LibreOffice.
Дополнительно сделан NSIS-скрипт для упрощения установки программы под Windows (пуск kicadbom2spec.exe).

[AVL]

Реализовал идею с промежуточным сервером.
Теперь нет версионной зависимости на уровне сопряжения программ и теоретически должно работать с любой версией OpenOffice / LibreOffice.

Текущая ревизия 4111.

Проверено и работает в Debian 6.0.7 (OpenOffice 3.2.1) и Windows 7 (проверены OpenOffice 3.1.1 и OpenOffice 3.4.1).

Под Windows теперь не требуется вообще устанавливать Python, поскольку задействован Python, идущий в поставке вместе с офисом.
OpenOffice / LibreOffice SDK соответственно тоже не нужен.
Нужно установить только сам офис (OpenOffice / LibreOffice).

Под Linux (по крайней мере Debian) как оказалось Python не идет в поставке с офисом. Разработчики дистрибутива это делают намеренно и используется системный Python. Системный Python, идущий в дистрибутиве Debian полностью совместим с uno библиотеками, идущими с офисом, который так же идет вместе с дистрибутивом Debian.

Сборку на ubuntu пока не проверял (сломалась виртуалка), но по идее действия должны быть следующие:

Код

sudo apt-get install bzr cmake g++ freeglut3-dev libwxgtk2.8-dev python-uno
bzr branch lp:~al-lunev/kicad/GOST-doc-gen
cd GOST-doc-gen
mkdir Release
cd Release
cmake ../. -DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON
make
sudo make install

Пакет python-dev больше не требуется.
Опцию -DUSE_GOST_DOC_GEN=ON убрал, достаточно указывать только -DKICAD_GOST=ON.

Сборка под винду теперь выполняется точно так же как и раньше, просто включая опцию KICAD_GOST:
-DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON

bat файл больше тоже не требуется (реализован поиск офиса и его питона из KiCadа).

[AVL]

В ревизии 4112 добавил поддержку Python 3.
Теперь проверен и работает LibreOffice 4.0.2 под виндой (он поставляется с Python 3).

[Барановский Конс...]

AVL, спасибо за проделанную работу!
Ubuntu 13.04 32bit ревизия 4111 собралась после небольших правок (см. diff.txt).
При попытке создать спецификацию последовательно появляются два сообщения:

Прикрепленные файлы

 diff.txt ( 1.62 килобайт ) Кол-во скачиваний: 73

 

[AVL]

AVL, спасибо за проделанную работу!
Ubuntu 13.04 32bit ревизия 4111 собралась после небольших правок (см. diff.txt).
При попытке создать спецификацию последовательно появляются два сообщения...

Константин, спасибо за помощь.

Установил новую виртуалку с ubuntu 13.04 32bit.

Проверил, mb_str тоже не работает (как раз из-за него вываливается ошибка).

Сейчас в результате вернул использование TO_UTF8() как было в предыдущих коммитах.
Но когда был применен TO_UTF8() в винде кодировка не правильно отображалась.
Сейчас добавил принудительное декодирование в UTF8 в uno_iface.py, и это помогло.

Перепроверил в debian, ubuntu, Windows 7 (OpenOffice 3.1.1, OpenOffice 3.4.1 и LibreOffice 4.0.2). Сейчас везде работает.

Текущая ревизия 4113.

[Барановский Конс...]

4113 - собралась и работает.

[AVL]

Всем привет.
В пятницу (10 мая) сделал запрос на слияние ветки lp:~al-lunev/kicad/GOST-doc-gen с lp:kicad.
Как и ожидалось, опять админы, пока в данном случае Жан-Пьер, противится.
Если кому интересно, читайте и участвуйте в этой "дискуссии": https://code.launchpad.net/~al-lunev/kicad/...n/+merge/163239

Основные камни преткновения:
1) Жан-Пьер считает, что встраивать данный инструмент в сам KiCad - это не правильно.
2) Жан-Пьер требует, чтобы исходники содержали литералы только на английском, а русский перевод делать через интернационализацию.

По 1-му пункту я ему объясняю, что иметь отдельное ПО - это не правильно и не удобно. И в данном случае технически не реально использовать промежуточный файл как он предлагает. Вдобавок я делаю менеджер компонентов, который постоянно читает/пишет атрибуты eeschemы. (Самое интересное, что в случае с pcad2kicad (изначально я его сделал отдельным исполняемым файлом, но в составе дерева исходников Кикада), они тогда уперлись и потребовали его переписать в виде плагина Pcbnew, то есть встроить в сам KiCad).

По 2-му пункту я ему объясняю, что GOST-doc-gen расчитан только на русскоязычных пользователей и сам ГОСТ на русском. Никак не предполагается, что генерируемые формы будут использоваться не русскоязычными пользователями. И зачем в таком случае усложнять жизнь мне и человеку, который это будет собирать?

Подробности и остальные аргументы читайте на https://code.launchpad.net/~al-lunev/kicad/...n/+merge/163239
Если требуется перевод на русский, пожалуйста, дайте знать.

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

Борьба с этими админами у меня уже продолжается с июня 2012, то есть уже год почти.
Уже все какие возможно капризы их выполнены, а к примеру pcad2kicadsch (lp:~pcad2kicad-committers/kicad/pcad2kicad) до сих пор существует в виде отдельного проекта и живет своей жизнью. Они до сих пор его не добавили в основную ветку! А pcad2kicadpcb добавили только в декабре 2012!

Я уже не говорю про попытки других разработчиков присылать им патчи и реакцию этих админов.

Мой план такой. Я сейчас еще понаблюдаю, что они решат по GOST-doc-gen. Если безрезультатно, то придется создать ветку lp:~GOST-committers/kicad/kicad или что-то вроде этого. Коммититься в нее. Синхронизироваться периодически с lp:kicad.
Условная компиляция KICAD_GOST - это и так по факту отдельный проект, собирается он только участниками этого форума для русскоязычных пользователей.
Исходный код части KICAD_GOST сопровождается тоже только разработчиками с этого форума. Так и так приходится самим синхронизироваться с изменениями, которые вне KICAD_GOST секции.

Значит тому и быть.

[AVL]

Юрий, спасибо за сборку.

Как и обещал, добавил GUI менеджер компонентов (ревизия 4115).
Поскольку данный менеджер (я не говорю про сам генератор GOST-doc-gen) по идее может применяться любыми пользователями Кикада (не только ГОСТ пользователи), исходники его полностью на английском с расчетом на использование интернационализации. Потребуется руссификация.

Возможности менеджера компонентов:
1) список всех компонентов схемы с отображением полной строки в примерном виде в каком это попадет в КД
2) добавление новых исполнений
3) возможность просмотра и работы со списком компонентов в разных плоскостях (полный список, постоянная часть, переменная часть для выбранного исполнения)
4) указание компоненту в каких исполнениях он присутствует
5) возможность задать значение "Не устанавливается". В результате будет сделана отметка в ПЭ3, и данный компонент не попадет в спецификацию.
6) редактирование атрибутов компонента
7) если есть поз.обозначения вида A1C1, то такие компоненты образуются в комплекты и в соответствующем виде отображаются в КД
8) возможность группового редактирования компонентов
9) все изменения сделанные в менеджере компонентов автоматически, не видимо для пользователя, отражаются в eeschema и наоборот, все изменения сделанные в eeschema появляются в менеджере компонентов
10) запуск генератора перечня элементов (ПЭ3) и спецификации из менеджера компонентов (должен быть установлен OpenOffice или LibreOffice)
Идея реализации данного менеджера компонентов похожа на проприетарный генератор перечней Брагина.
------------------------------

У меня вопрос к Юрию Викулову и Андрею Федорушкову по руссификации:
На сколько я понимаю придется создавать ветку документации (bzr branch lp:~kicad-developers/kicad/doc)? Раз пока GOST-doc-gen не находится в lp:kicad и не известно будет он ли вообще там.
То есть я вижу сейчас следующую проблему. Если добавлю перевод в lp:~kicad-developers/kicad/doc, то скорее всего мой перевод будет затерт следующим коммитом, который будет сделан на базе lp:kicad, так как в lp:kicad отсутствуют фразы, которые есть в lp:~al-lunev/kicad/GOST-doc-gen.
Я сегодня пробовал запустить poedit, и он если видит, что в новых коммитах какие-то фразы уже отсутствуют, то выкидывает их, и результат сохраняется без старых фраз.
Поэтому я вижу выход из ситуации - создать ветку документации, которая будет в паре с lp:~al-lunev/kicad/GOST-doc-gen.

Если все так, то, Юрий и Андрей, вам бы это не помешало делать сборку, если документация будет в другой ветке отличной от lp:~kicad-developers/kicad/doc?
Либо может есть другой вариант как поступить с документацией?

[viknn]

Если все так, то вам бы это не помешало делать сборку, если документация будет в другой ветке отличной от lp:~kicad-developers/kicad/doc? Либо может есть другой вариант как поступить с документацией?

Думаю, что это не помешает взять ru-перевод из отдельной ветки для GOST-doc-gen, поместить его в GOST-сборку.
Надо подумать о методе пост-копирования ru-перевода новых сообщений из новых версий развития основной ветки kicad.
Может часть сообщений, нужных только ru-сообществу, делать изначально ru.

[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]

From: Барановский Константин <.....@gmail.com>

Нашелся баг в GOST-doc-gen.
Запускаю EEschema, открываю demos/multivibrator.sch, далее в меню Инструменты-GOST tools в появившемся мастере Variable part, var. no. выбераю 01 (по умолчанию 00) - дальше crash.

Ubuntu говорит:
eeschema crashed with SIGSERV in wxBaseArrayPtrVoid::GetCount()

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

Поразбирался с этой проблемой, с одной стороны обнаружил, что wxFrame некорректно обрабатывает событие wxEVT_ACTIVATE (фрейм теряет фокус даже, если нажать на ComboBox этого фрейма), с другой стороны я не учел, что при добавлении нового исполнения, выпадет диалоговое окно, и фрейм по нормальной логике потеряет фокус.

Пока решил вернуться к временному прежнему решению - окно менеджера компонента открывается во весь экран и не дает перейти на eeschema (некое подобие модального окна). Поработав в менеджере компонентов, его нужно закрыть, чтобы поработать дальше в eeschema. Дальше, если нужно работать с менежером компонентов, то опять его открыть. Переброс изменений из менеджера компонентов в eeschema происходит в момент закрытия окна менеджера компонентов.

Это временная мера. Буду дорабатывать этот механизм, чтобы все-таки окно менеджера было независимым окном и было бы можно работать одновременно с eeschema и менеджером компонентов, не закрывая каждый раз окно менеджера компонентов.

По крайней мере сейчас ничего не "падает".

Текущая ревизия 4117 (lp:~kicad-gost-committers/kicad/kicad).

[AVL]

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

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

[tema-electric]

Собрал последнюю ревизию из репозитария lp:~kicad-gost-committers/kicad/kicad
Кроме нее больше ничего не докачивал.

Вылезает окно с ошибкой при попытке сгенерировать перечень: RPC_DOC_IFACE: Unable to load document

Код

Application: KiCad
Version: (2013-05-15 BZR 4117 GOST)-testing
Build: wxWidgets 2.8.10 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.3,wx containers,compatible with 2.6)
Platform: Linux 2.6.32-47-generic i686, 32 bit, Little endian, wxGTK
Boost version: 1.53.0
Options: USE_PCBNEW_NANOMETRES=ON
         KICAD_GOST=ON
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=OFF
         KICAD_SCRIPTING_MODULES=OFF
         KICAD_SCRIPTING_WXPYTHON=OFF

Собирал с такими опциями

Код

cmake -DwxUSE_UNICODE=ON -DKICAD_GOST=ON -DKICAD_TESTING_VERSION=ON -DKICAD_MINIZIP=OFF USE_PCBNEW_NANOMETRES=ON USE_BOOST_POLYGON_LIBRARY -DCMAKE_INSTALL_PREFIX=/usr ../

Что я сделал не так?

[AVL]

...
Вылезает окно с ошибкой при попытке сгенерировать перечень: RPC_DOC_IFACE: Unable to load document
...

А какое наименование дистрибутива Linux? полностью?

[tema-electric]

А какое наименование дистрибутива Linux? полностью?

Код

cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.4 LTS"

Это может быть связано с тем, что я не заполнил таблицу? Хотя по идее "как-то" заполненный документ должен был сформироваться.

[AVL]

Код

cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.4 LTS"

Это может быть связано с тем, что я не заполнил таблицу? Хотя по идее "как-то" заполненный документ должен был сформироваться.

Для Ubuntu 13.04 32-bit необходимо было установить пакет python-uno:
sudo apt-get install python-uno

Скорее всего для любой версии Ubuntu данный пакет необходимо установить.
Есть подозрение, что и для других дистрибутивов Linux это будет необходимо. Пока не знаю, нужно собрать статистику.

Однако, судя по ошибке, не похоже, что это из-за неустановленного python-uno.
В любом случае необходимо установить этот пакет (если еще не установлен).
Если не поможет, я сегодня ночью, либо завтра установлю виртуалку с Ubuntu 10.04, посмотрю что не так.

Насчет незаполненной таблицы, нет не из-за этого. В данной ситуации все равно можно сгенерировать КД, просто она будет пустая (будет отображено содержимое шаблонов в результирующих odt файлах).

[tema-electric]

sudo apt-get install python-uno

Код

Уже установлена самая новая версия python-uno.

На машине нет OpenOffice. Стоит только LibreOffice 4.0. Устанаваливался из deb пакетов.
Еще есть вопрос по русификации самого окна GOST_Tools. Нужно докачать какие-то пакеты или это просто временно так сделано?

[AVL]

Код

Уже установлена самая новая версия python-uno.

На машине нет OpenOffice. Стоит только LibreOffice 4.0. Устанаваливался из deb пакетов.
Еще есть вопрос по русификации самого окна GOST_Tools. Нужно докачать какие-то пакеты или это просто временно так сделано?

LibreOffice тоже поддержан. Как раз в Ubuntu 13.04 выполнялась отладка на базе LibreOffice.
OK, тогда посмотрю на виртуалке что получится.

Руссификация в процессе. Ветку с документацией, соответствующую ветке lp:~kicad-gost-committers/kicad/kicad, создал здесь: lp:~kicad-gost-committers/kicad/doc

[AVL]

Собрал последнюю ревизию из репозитария lp:~kicad-gost-committers/kicad/kicad
Кроме нее больше ничего не докачивал.

Вылезает окно с ошибкой при попытке сгенерировать перечень: RPC_DOC_IFACE: Unable to load document

Код

Application: KiCad
Version: (2013-05-15 BZR 4117 GOST)-testing
Build: wxWidgets 2.8.10 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.3,wx containers,compatible with 2.6)
Platform: Linux 2.6.32-47-generic i686, 32 bit, Little endian, wxGTK
Boost version: 1.53.0
Options: USE_PCBNEW_NANOMETRES=ON
         KICAD_GOST=ON
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=OFF
         KICAD_SCRIPTING_MODULES=OFF
         KICAD_SCRIPTING_WXPYTHON=OFF

Собирал с такими опциями

Код

cmake -DwxUSE_UNICODE=ON -DKICAD_GOST=ON -DKICAD_TESTING_VERSION=ON -DKICAD_MINIZIP=OFF USE_PCBNEW_NANOMETRES=ON USE_BOOST_POLYGON_LIBRARY -DCMAKE_INSTALL_PREFIX=/usr ../

Что я сделал не так?

Установил Ubuntu 10.04 (http://releases.ubuntu.com/lucid/ubuntu-10.04.4-desktop-i386.iso) на виртуалку.

выполнил:

Код

sudo apt-get install bzr cmake g++ freeglut3-dev libwxgtk2.8-dev
bzr branch lp:~kicad-gost-committers/kicad/kicad
cd kicad
mkdir Release
cd Release
cmake ../. -DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON
make
sudo make install

Пакет python-uno не устанавливал, он уже был установлен. (получается что данный пакет предустановлен по крайней мере в Debian 6 (Squeeze) и Ubuntu 10.04, а вот в Ubuntu 13.04 он не предустановлен почему-то).

У меня все запустилось, работает.
В этом дистрибутиве предустановлен OpenOffice 3.2.0 и системный Python 2.6.5.

Попробую приблизиться к Вашей конфигурации, tema-electric.

Выполнил все обновления, которые предложил Update Manager. Опять все работает.

LibreOffice в репозитории Ubuntu для Ubuntu 10.04 вообще нет.
А LibreOffice 4.0.3 есть в Ubuntu 13.04. Но чувствую, если пытаться установить эти пакеты из репозитория Ubuntu raring, то выполнится апгрейд всего дистрибутива до Ubuntu raring.

Пошел другим путем, скачал http://www.libreoffice.org/DownloadRedirec..._x86_deb.tar.gz
далее:

Код

sudo apt-get remove open-office.org*
tar xfz LibreOffice_4.0.3_Linux_x86_deb.tar.gz
cd LibreOffice_4.0.3_Linux_x86_deb
sudo dpkg -i *.deb
cd desktop-integration
sudo dpkg -i *.deb

При запуске генератора перечня выпадает ошибка RPC_DOC_IFACE: Unable to connect to RPC document server
Проверяю системный Python так и остался версии 2.6.5:

Код

$ python --version
Python 2.6.5

А вот в директории /opt/libreoffice4.0/program есть свой Python:

Код

$ /opt/libreoffice4.0/program/python --version
Python 3.3.0

В данном случае понятно откуда ошибка RPC_DOC_IFACE: Unable to connect to RPC document server
В дистрибутивах Debian Squeeze и Ubuntu raring предустановленные офисы идут без своего питона. Питон используется системный.
В GOST-doc-gen пока на это и рассчитывается, что используется системный Python под Linux.
Получается, что при другом способе установки (установка пакетов deb из LibreOffice_4.0.3_Linux_x86_deb.tar.gz) как и в Windows используется Python, идущий в поставке с офисом.
Как данную ситуацию исправить - мне понятно, это доработаем.

А вот все-таки откуда берется ошибка RPC_DOC_IFACE: Unable to load document мне не понятно
tema-electric, есть идеи, почему не получается повторить ситуацию как у Вас?
Также пришлите, пожалуйста, результат выполнения команды:
$ python --version

[tema-electric]

В этом дистрибутиве предустановлен OpenOffice 3.2.0 и системный Python 2.6.5.

Open Office вроде штатный шел, но я его снес после уставновки LibreOffice. Сносил культурно через GUI. Не помню, как называется штатная утилита Update Center или Package Center или ....

$ python --version

По питону станет известно только в понедельник. Тачанка на работе .
Есть вероятность, что стоит питон 2.7, но она очень маленькая и там инсталяция была через altinstall. Это точно было на старой системе, а на новой, вроде, не успел еще.

А вот все-таки откуда берется ошибка RPC_DOC_IFACE: Unable to load document

Хорошо бы знать, что именно пытается сделать в это время python.
Может права ограничены? Хотя у меня ubuntu недавно установлена, и много дел в ней я еще не успел наворотить.

1) Могу поставить штатный офис, и сравнить.
2) Можно сгенерировать перечень установленных пакетов, и сравнить. Не запомнил как это делается, но знаю что возможно.
3) Запустить KiCAD через консоль, посмотреть что он в нее выкидывает. Может там больше инфы.

[AVL]

3) Запустить KiCAD через консоль, посмотреть что он в нее выкидывает. Может там больше инфы.

Да, сначала давайте так и сделаем.

В любом случае добавил поддержку инсталляций OpenOffice/LibreOffice, которые поставляются вместе с Python в случае Linux (это те установочные пакеты, которые можно скачать с сайтов www.openoffice.org и www.libreoffice.org).

текущая ревизия 4119 (lp:~kicad-gost-committers/kicad/kicad)

[AVL]

У меня еще вопрос к Юрию Викулову и Андрею Федорушкову по руссификации (или может тоже кто подскажет). Делаю следующее:
1) bzr branch lp:kicad
2) bzr update -r4115 (на ревизию, для которой в последний раз делался русский перевод)
3) bzr branch lp:~kicad-developers/kicad/doc (текущая ревизия 441)
4) запускаю poedit (версия 1.4.2)
5) открываю File->Open, выбираю файл в хранилище документации: doc/internat/ru/kicad.po
6) открываю Catalog->Settings->Paths, изменяю Base path: с /home/faa/Project/kicad-dev на корневую директорию моего клона lp:kicad
7) нажимаю Catalog->Update from sources. Появляется окошко Update summary, в котором написано, что изменений нет (0 new, 0 obsolete)
8) нажимаю OK
9) нажимаю File->Save, после чего файл internat/ru/kicad.po примерно на 50% отличается от оригинала (пересортица строк по всему файлу).

Из-за чего это может быть? Может влияет версия poedit? Кто подскажет тогда с помощью какой версии poedit был сохранен файл internat/ru/kicad.po (в его содержимом версия poedit не указана).
Не хочется добавлять перевод менеджера компонентов на русский язык, в результате чего появится порядка 20 новых строк, но при этом весь файл internat/ru/kicad.po изменится до неузнаваемости.

[AVL]

Как обещал, влил ветку lp:~kicad-gost-committers/kicad/pcad2kicad в lp:~kicad-gost-committers/kicad/kicad
ветку lp:~kicad-gost-committers/kicad/pcad2kicad удалил.

Также добавил в диалоговое окно "о программе" ссылку на этот форум (кто-то помню на этом форуме предлагал это сделать).

Добавил в eeschema пункт меню: Tools->Run pcad2kicadsch converter, чтобы не искать и не запускать конвертер из командной строки.

[viknn]

Кто подскажет тогда с помощью какой версии poedit был сохранен файл internat/ru/kicad.po (в его содержимом версия poedit не указана).
Не хочется добавлять перевод менеджера компонентов на русский язык, в результате чего появится порядка 20 новых строк, но при этом весь файл internat/ru/kicad.po изменится до неузнаваемости.

Я использую poedit 1.4.1 в Windows. Что у Андрея не знаю, он формирует ru/kicad.po/mo.
Предложения по улучшению перевода отсылаю ему или через форум. Исходники давно не сканировал.

[tema-electric]

Код

$ python --version
Python 2.6.5

В консольке тихо. Никаких записей об ошибках.
Запустил kicad под root, бестолку.
Поставил штатный OpenOffice. Не помогло.
Снес python-uno и установил заново. Не помогло.

Пересобираю последнюю версию. Алгоритм сборки один и тот же всегда.
Хочу обратить внимание, на то что инсталирую в /usr. Помнится, штатный кикад вставал в /usr/local
Установка через checkinstall не всегда заканчивалась хорошо. В таких случаях я использовал sudo dpkg -i --force-all kicad.
Не знаю, на сколько это плохо. С ГОСТовским KiCAD пока еще не применял.
Установка всегда идет поверх существующей версии.

Код

$ cmake -DwxUSE_UNICODE=ON -DKICAD_GOST=ON -DKICAD_TESTING_VERSION=ON -DKICAD_MINIZIP=OFF USE_PCBNEW_NANOMETRES=ON USE_BOOST_POLYGON_LIBRARY -DCMAKE_INSTALL_PREFIX=/usr ../
$make
$sudo checkinstall -D --pkgname kicad

Пересобрал

Код

Application: KiCad
Version: (2013-05-19 BZR 4123 GOST)-testing
Build: wxWidgets 2.8.10 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.3,wx containers,compatible with 2.6)
Platform: Linux 2.6.32-47-generic i686, 32 bit, Little endian, wxGTK
Boost version: 1.53.0
Options: USE_PCBNEW_NANOMETRES=ON
         KICAD_GOST=ON
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=OFF
         KICAD_SCRIPTING_MODULES=OFF
         KICAD_SCRIPTING_WXPYTHON=OFF

Все также: RPC_DOC_IFACE: Unable to load document

Прикладываю список пакетов в моей системе. Может у меня чего-то не хватает.
 packagelist.txt ( 234.61 килобайт ) Кол-во скачиваний: 856

[AVL]

Пересобираю последнюю версию. Алгоритм сборки один и тот же всегда.
Хочу обратить внимание, на то что инсталирую в /usr. Помнится, штатный кикад вставал в /usr/local
Установка через checkinstall не всегда заканчивалась хорошо. В таких случаях я использовал sudo dpkg -i --force-all kicad.
Не знаю, на сколько это плохо. С ГОСТовским KiCAD пока еще не применял.
Установка всегда идет поверх существующей версии.

Код

$ cmake -DwxUSE_UNICODE=ON -DKICAD_GOST=ON -DKICAD_TESTING_VERSION=ON -DKICAD_MINIZIP=OFF USE_PCBNEW_NANOMETRES=ON USE_BOOST_POLYGON_LIBRARY -DCMAKE_INSTALL_PREFIX=/usr ../
$make
$sudo checkinstall -D --pkgname kicad

Прикладываю список пакетов в моей системе. Может у меня чего-то не хватает.
 packagelist.txt ( 234.61 килобайт ) Кол-во скачиваний: 856

Удалил я свою предыдущую установку и повторил именно как у Вас:

Код

$ cmake -DwxUSE_UNICODE=ON -DKICAD_GOST=ON -DKICAD_TESTING_VERSION=ON -DKICAD_MINIZIP=OFF USE_PCBNEW_NANOMETRES=ON USE_BOOST_POLYGON_LIBRARY -DCMAKE_INSTALL_PREFIX=/usr ../
$make
$sudo checkinstall -D --pkgname kicad

с параметрами что-то не так: USE_PCBNEW_NANOMETRES=ON USE_BOOST_POLYGON_LIBRARY
по идее ж должно -D перед ними. Но это не играет роли сейчас.

В результате установился kicad в /usr и все работает.
Прикладываю свой список пакетов.

Хочу обратить внимание, что в Вашем списке пакетов мне подозрительно место:

Код

ii  kicad                                             20130516-1                                      Package created with checkinstall 1.6.1
ii  kicad-common                                      3060bzr~lucid-1                                 Common files used by kicad
ii  kicad-doc-ru                                      3060bzr~lucid-1                                 Kicad help files (Russian)

То есть часть общих пакетов идут из одной установки, а kicad - из другой.
Предлагаю сделать следующее:

Код

sudo dpkg -r kicad-common
sudo dpkg -r kicad
sudo dpkg -i kicad...deb (который Вы собрали)

Я попробовал сэмулировать такую же ситуацию как у Вас, но мне не удалось установить пакет, выдалась ошибка конфликта, что логично:

Код

sudo dpkg -r kicad
sudo apt-get install kicad
sudo apt-get remove kicad (в результате пакеты kicad-common и остальные кроме пакета kicad остались в системе)
a-lunev@a-lunev-laptop:~/bzr/kicad/Release$ sudo dpkg -i kicad_20130520-1_i386.deb
Selecting previously deselected package kicad.
(Reading database ... 136627 files and directories currently installed.)
Unpacking kicad (from kicad_20130520-1_i386.deb) ...
dpkg: error processing kicad_20130520-1_i386.deb (--install):
trying to overwrite '/usr/share/kicad/template/kicad.pro', which is also in package kicad-common 0:0.0.20090216-1
Errors were encountered while processing:
kicad_20130520-1_i386.deb

Прикрепленные файлы

 working_packagelist.txt ( 191.27 килобайт ) Кол-во скачиваний: 219

 

[tema-electric]

То есть часть общих пакетов идут из одной установки, а kicad - из другой.
Предлагаю сделать следующее:

Код

sudo dpkg -r kicad-common
sudo dpkg -r kicad
sudo dpkg -i kicad...deb (который Вы собрали)

Привычка с винды осталась поверх закатывать. Да и библиотеки вроде в common лежат.
Попробовал. Даже kicad-doc-ru удалил. Бестолку.

Я попробовал сэмулировать такую же ситуацию как у Вас, но мне не удалось установить пакет, выдалась ошибка конфликта, что логично:

ммм, у dpkg есть ключик --force-all, который поставит один кикад поверх другого.

Попробовал многое. Сравнил пакеты с разных систем и доустановил отсутствующие (freeglut3-dev). Еще питон 3.1 поставил на всякий случай.
Пробовал снести весь kicad полностью (apt-get purge kicad) и поставить заново. Заколдованный круг.
Ваш deb пакет подойдет для моей машины или нет? Может проблема в сборке? Что-то где-то не так компилится...

[AVL]

Привычка с винды осталась поверх закатывать. Да и библиотеки вроде в common лежат.
Попробовал. Даже kicad-doc-ru удалил. Бестолку.


ммм, у dpkg есть ключик --force-all, который поставит один кикад поверх другого.

Попробовал многое. Сравнил пакеты с разных систем и доустановил отсутствующие (freeglut3-dev). Еще питон 3.1 поставил на всякий случай.
Пробовал снести весь kicad полностью (apt-get purge kicad) и поставить заново. Заколдованный круг.
Ваш deb пакет подойдет для моей машины или нет? Может проблема в сборке? Что-то где-то не так компилится...

Сегодняшний deb пакет смогу дать поздно вечером только, дома он.

1) Попробуйте выполнить which kicad
Допустим результат будет /usr/local/bin/kicad
2) Далее нужно выполнить ls -la /usr/local/bin/kicad
в списке должно показать директорию GOST-doc-gen
3) Далее нужно выполнить ls -laR /usr/local/share/kicad/GOST-doc-gen

Результат выполнения каждой из 3-х команд, пожалуйста, покажите.

Улучшил диагностику открытия файлов odt в ревизии 4124.
Пересобрал для ревизии 4124 deb файл (прикреплен к сообщению).
Там теперь должна быть ошибка с указанием пути к файлу, который не может открыть через RPC. Пожалуйста, пришлите эту инфу тоже.

Сообщение отредактировал AVL - May 20 2013, 21:06

Прикрепленные файлы

 kicad_20130520_1_i386.deb.gz ( 8.33 мегабайт ) Кол-во скачиваний: 20

 

[tema-electric]

Результат выполнения каждой из 3-х команд, пожалуйста, покажите.

Код

$which kicad
/usr/bin/kicad

ls -la /usr/bin/kicad
-rwxr-xr-x 1 root root 840836 2013-05-20 17:00 /usr/bin/kicad

$ ls -laR /usr/share/kicad/GOST-doc-gen
/usr/share/kicad/GOST-doc-gen:
итого 20
drwxr-xr-x 3 root root 4096 2013-05-21 08:58 .
drwxr-xr-x 5 root root 4096 2013-05-20 17:37 ..
drwxr-xr-x 2 root root 4096 2013-05-21 08:58 templates
-rw-r--r-- 1 root root 4971 2013-05-18 04:01 uno_iface.py

/usr/share/kicad/GOST-doc-gen/templates:
итого 100
drwxr-xr-x 2 root root  4096 2013-05-21 08:58 .
drwxr-xr-x 3 root root  4096 2013-05-21 08:58 ..
-rw-r--r-- 1 root root 17087 2013-05-18 04:01 CompIndexFirstSheet_template.odt
-rw-r--r-- 1 root root 16596 2013-05-18 04:01 CompIndexLastSheet_template.odt
-rw-r--r-- 1 root root 14211 2013-05-18 04:01 CompIndexMiddleSheet_template.odt
-rw-r--r-- 1 root root 16632 2013-05-18 04:01 SpecificationFirstSheet_template.odt
-rw-r--r-- 1 root root 14964 2013-05-18 04:01 SpecificationMiddleSheet_template.odt

Поставил вашу сборку, окошко выпало, соответственно, с другой подписью:

Код

RPC_DOC_IFACE: Unable to load document
RPC command: LoadDocument {file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt}

[AVL]

ls -la /usr/bin/kicad
-rwxr-xr-x 1 root root 840836 2013-05-20 17:00 /usr/bin/kicad

$ ls -laR /usr/share/kicad/GOST-doc-gen
/usr/share/kicad/GOST-doc-gen:
итого 20
drwxr-xr-x 3 root root 4096 2013-05-21 08:58 .
drwxr-xr-x 5 root root 4096 2013-05-20 17:37 ..
drwxr-xr-x 2 root root 4096 2013-05-21 08:58 templates
-rw-r--r-- 1 root root 4971 2013-05-18 04:01 uno_iface.py

Добавил логирование RPC команд в файл uno_iface.py, приходящих из eeschema.
Нужно выполнить:
1) распаковать прикрепленный архив
2) sudo cp uno_iface.py /share/kicad/GOST-doc-gen/templates/uno_iface.py
3) запустить eeschema, попытаться сгенерировать КД
4) в Вашей HOME директории должен будет появиться файл kicad_uno_iface.log, пожалуйста, пришлите его.

Прикрепленные файлы

 uno_iface.py.zip ( 1.86 килобайт ) Кол-во скачиваний: 14

 

[tema-electric]

2) sudo cp uno_iface.py /share/kicad/GOST-doc-gen/templates/uno_iface.py

Немного кривой путь ... но я поправил как надо ( /usr/share/kicad/GOST-doc-gen/uno_iface.py).
Содержимое лога.

Код

b'Connect'
b'LoadDocument {file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt}'
b'Exit'

[AVL]

Немного кривой путь ... но я поправил как надо ( /usr/share/kicad/GOST-doc-gen/uno_iface.py).
Содержимое лога.

Код

b'Connect'
b'LoadDocument {file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt}'
b'Exit'

Еще раз, пожалуйста )

Прикрепленные файлы

 uno_iface.py.zip ( 1.93 килобайт ) Кол-во скачиваний: 15

 

[tema-electric]

Еще раз, пожалуйста )

Код

b'Connect'
b'LoadDocument {file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt}'
received LoadDocument cmd
running loadComponentFromURL(): file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt
sent FAILED
b'Exit'

[AVL]

Код

b'Connect'
b'LoadDocument {file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt}'
received LoadDocument cmd
running loadComponentFromURL(): file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt
sent FAILED
b'Exit'

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

Приложил еще один вариант скрипта.
1) нужно сделать тоже самое еще раз как в предыдущем сообщении и прислать лог.
2) далее выполнить и прислать результат:

Код

ls /opt

3) далее выполнить soffice из командной строки (именно так, чтобы убедиться, что офис так запускается), должен открыться офис. В меню Help->About... скопировать полную версию офиса и прислать это значение.

Просьба в системе ничего не переустанавливать пока (офис, питон, python-uno).

[tema-electric]

Я так понимаю, что выпадает только ошибка и окно офиса не открывается вообще в этот момент?

Нет, офис вообще себя никак не проявляет.

Приложил еще один вариант скрипта.

Скрипт будущего Тю-тю.

Код

ls /opt

$ ls /opt
Adobe deadbeef libreoffice4.0

выполнить soffice из командной строки

soffice - неа, не работает. Либра запускается иначе ... libreoffice4.0

[AVL]

Нет, офис вообще себя никак не проявляет.

Скрипт будущего Тю-тю.

$ ls /opt
Adobe deadbeef libreoffice4.0

soffice - неа, не работает. Либра запускается иначе ... libreoffice4.0

Эхх, забыл скрипт я приложить ) Уже не дома я, нет его с собой.

/opt/libreoffice4.0/program/python --version
Что пишет?

Я понимаю таким образом же запускается? :
/opt/libreoffice4.0/program/soffice

Если да, то какая версия в Help->About... ?

[tema-electric]

Код

$ /opt/libreoffice4.0/program/python --version
Python 3.3.0

Help->About Версия 4.0.1.2 (ID сборки: 84102822e3d61eb989ddd325abf1ac077904985)

[AVL]

Код

$ /opt/libreoffice4.0/program/python --version
Python 3.3.0

Help->About Версия 4.0.1.2 (ID сборки: 84102822e3d61eb989ddd325abf1ac077904985)

С версиями все в порядке.

Попробуйте сделать следующее:
1) убедиться, что никакие процессы soffice не запущены:
$ ps aux | grep soffice
a-lunev 17890 0.0 0.0 7548 880 pts/5 S+ 14:59 0:00 grep soffice

(никаких других строк быть не должно)

2) запустить интерпретатор
$ /opt/libreoffice4.0/program/python

3) прямо в окне интерпретатора вбить последовательно строки:
>>> import uno
>>> local = uno.getComponentContext()
>>> resolver = local.ServiceManager.createInstanceWithContext( "com.sun.star.bridge.UnoUrlResolver", local )
>>> context = resolver.resolve( "uno:socket,host=localhost,port=8100;urp;StarOffice.ComponentContext" )
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
__main__.NoConnectException: Connector : couldn't connect to socket (Success)

Должна появиться ошибка как указано.

4) Не закрывая интерпретатор, выполнить в другом терминале:
$ /opt/libreoffice4.0/program/soffice --invisible "--accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"

5) повторить в интерпретаторе:
>>> context = resolver.resolve( "uno:socket,host=localhost,port=8100;urp;StarOffice.ComponentContext" )
ошибок быть не должно теперь

6) далее:
>>> desktop = context.ServiceManager.createInstanceWithContext( "com.sun.star.frame.Desktop", context )
>>> document = desktop.loadComponentFromURL( "file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt", "_blank", 0, () )

должен открыться libreoffice с открытым документом

[tema-electric]

должен открыться libreoffice с открытым документом

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

Выглядело это так ...

Код

$ ps aux | grep soffice
tenzor    1761 52.5  2.9 264192 53688 ?        Sl   May20 1047:14 /opt/libreoffice4.0/program/soffice.bin --quickstart --nologo --nodefault

tenzor    2257  0.0  0.5 188196 10664 ?        Sl   May20   0:02 /usr/lib/openoffice/program/soffice.bin -invisible -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager --invisible --accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager -splash-pipe=4

tenzor    2552  0.0  0.0   3368   896 pts/2    S+   18:08   0:00 grep --color=auto soffice

root      2837  2.7  0.1 130252  3356 ?        Sl   May20  53:43 /usr/lib/openoffice/program/soffice.bin -invisible -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager -splash-pipe=4

После всего что я проделал, запустил генератор перечня в KiCAD и он таки запустил офис и показал мне форму, правда после закрытия этой формы посыпались окна с ошибками. Остальное завтра. Рабочий день окончен, увы.

[AVL]

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

Выглядело это так ...

Код

$ ps aux | grep soffice
tenzor    1761 52.5  2.9 264192 53688 ?        Sl   May20 1047:14 /opt/libreoffice4.0/program/soffice.bin --quickstart --nologo --nodefault

tenzor    2257  0.0  0.5 188196 10664 ?        Sl   May20   0:02 /usr/lib/openoffice/program/soffice.bin -invisible -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager --invisible --accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager -splash-pipe=4

tenzor    2552  0.0  0.0   3368   896 pts/2    S+   18:08   0:00 grep --color=auto soffice

root      2837  2.7  0.1 130252  3356 ?        Sl   May20  53:43 /usr/lib/openoffice/program/soffice.bin -invisible -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager -splash-pipe=4

После всего что я проделал, запустил генератор перечня в KiCAD и он таки запустил офис и показал мне форму, правда после закрытия этой формы посыпались окна с ошибками. Остальное завтра. Рабочий день окончен, увы.

Не могу понять откуда такая строка появилась:
"tenzor 2257 0.0 0.5 188196 10664 ? Sl May20 0:02 /usr/lib/openoffice/program/soffice.bin -invisible -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager --invisible --accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager -splash-pipe=4"

Насчет закрытия формы, есть сейчас такой нюанс, если форма еще не успела полностью заполниться, и ее закрыть, то начнут выпадать ошибки в окне менеджера компонентов. То есть GOST-doc-gen продолжает заполнять форму, а формы уже нет.
Сейчас нужно либо дожидаться пока КД сгенерируется и заполнится до последнего листа, либо ждать пока доработаю этот момент

[tema-electric]

Не могу понять откуда такая строка появилась:

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

[tema-electric]

Мягко говоря, аномалия. Перезапустил тачанку сегодня:

Код

$ ps aux | grep soffice
tenzor    1790  0.3  5.5 264308 100356 ?       Sl   09:09   0:04 /opt/libreoffice4.0/program/soffice.bin --quickstart --nologo --nodefault
tenzor    2568  0.0  0.0   3364   828 pts/0    S+   09:30   0:00 grep --color=auto soffice

И что самое непонятное, GOST Tools работает. Ему больше ничего не надо. Неужели надо было перезагрузиться?

У GOST Component manager нет пока русификации? Я залил с launchpad вашу ветку kicad/doc.
Поле "Наименование" содержит названия типа Capacitor ... Resistor ...
Из интересных особенностей при генерации ПЭ ))
Первый лист: C34 1 Not installed
Второй лист: C100,C101 2 Не устанавливаются

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

Спасибо

[AVL]

Мягко говоря, аномалия. Перезапустил тачанку сегодня:

Код

$ ps aux | grep soffice
tenzor    1790  0.3  5.5 264308 100356 ?       Sl   09:09   0:04 /opt/libreoffice4.0/program/soffice.bin --quickstart --nologo --nodefault
tenzor    2568  0.0  0.0   3364   828 pts/0    S+   09:30   0:00 grep --color=auto soffice

И что самое непонятное, GOST Tools работает. Ему больше ничего не надо. Неужели надо было перезагрузиться?

У GOST Component manager нет пока русификации? Я залил с launchpad вашу ветку kicad/doc.
Поле "Наименование" содержит названия типа Capacitor ... Resistor ...
Из интересных особенностей при генерации ПЭ ))
Первый лист: C34 1 Not installed
Второй лист: C100,C101 2 Не устанавливаются

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

Спасибо

Насчет перезагрузки, видимо из-за того, что оказались установлены оба типа офиса, да еще и одновременно запущены, были такие глюки. Наверно можно было не перезагружать, а просто сделать sudo kill лишних процессов.

Ветку lp:~kicad-gost-committers/kicad/doc пока только создал, но русский перевод еще не добавил. У меня пока не решенный вопрос с poedit, о котором я писал ранее.

Насчет
"Из интересных особенностей при генерации ПЭ ))
Первый лист: C34 1 Not installed
Второй лист: C100,C101 2 Не устанавливаются"
так и есть. Изначально я делал все на русском, поскольку бессмысленно делать еще на каком-то другом языке.
Был разговор с Jean-Pierre, он требовал, чтобы GOST-doc-gen был по умолчанию на английском. Согласиться с этим не могу.
Однако, для менеджера компонентов думаю есть смысл поддержки интернационализации, потому что он дает функции, которые будут полезны любому пользователю.
Таким образом, начал адаптировать на английский. А поскольку грамматика у русского и английского разная, то поплыла логика формирования падежей, числа и т.д.
Пока пришел к выводу, что GUI можно делать через интернационализацию, а содержимое выпадающих списков таких как поле "Наименование", надо формировать на основе языка, выбранного где-то в меню.
К примеру, я люблю GUI на английском, но значения в выпадающих списках менеджера компонентов мне нужны только на русском. Также такая опция выбора языка в меню дала бы возможность четко определять логику по формированию языковых конструкций в самом GOST-doc-gen в зависимости от языка. Так что буду это дорабатывать.

[Aldan]

Самая острая фаза ремонта моей квартиры миновала и у меня стало появляться немного времени для форума. Первым делом решил потестировать возможность вывода текстовой документации. Поскольку вариант от AVL не требует что-то доустанавливать (а ЛибреОфис у меня и так уже установлен), то я остановился именно на нем. Скачал сборку для винды kicad_ins_gost_docgen_4115 с ftp://ftp.kicad.ru/pub/kicad/kicad_eskd_doc/lunev_set/ и открыл схему проекта. Далее, зашел в «инструменты» и запустил «GOST Tools” и в раскрывшемся окне зашел в “файл» и выбрал генерацию спецификации. После этого запустился ЛибреОфис и показал пустой бланк (нет ни названия схемы, ни компонентов в списке).
Казалось бы, работая с конкретной схемой, можно надеяться, что все ее атрибуты будут автоматически использованы при формировании документа, а у меня что-то ничего не получилось.
Каких-то дополнительных возможностей изменить сложившуюся ситуацию к лучшему в опциях менеджера перечня я не обнаружил, да и хоть какая-то краткая инструкция по использованию GOST Tools мне на глаза тоже не попалась. Делаю вывод, ремонт квартиры совсем меня доканал и я не врубаюсь в то, что очевидно для для остальных форумцев, которые успешно генерят себе текстовую документацию в своих проектах и в ус не дуют.
AVL, подскажите, что нужно сделать, чтобы бланк спецификации был сгенерирован с заполненными полями.

[AVL]

Самая острая фаза ремонта моей квартиры миновала и у меня стало появляться немного времени для форума. Первым делом решил потестировать возможность вывода текстовой документации. Поскольку вариант от AVL не требует что-то доустанавливать (а ЛибреОфис у меня и так уже установлен), то я остановился именно на нем. Скачал сборку для винды kicad_ins_gost_docgen_4115 с ftp://ftp.kicad.ru/pub/kicad/kicad_eskd_doc/lunev_set/ и открыл схему проекта. Далее, зашел в «инструменты» и запустил «GOST Tools” и в раскрывшемся окне зашел в “файл» и выбрал генерацию спецификации. После этого запустился ЛибреОфис и показал пустой бланк (нет ни названия схемы, ни компонентов в списке).
Казалось бы, работая с конкретной схемой, можно надеяться, что все ее атрибуты будут автоматически использованы при формировании документа, а у меня что-то ничего не получилось.
Каких-то дополнительных возможностей изменить сложившуюся ситуацию к лучшему в опциях менеджера перечня я не обнаружил, да и хоть какая-то краткая инструкция по использованию GOST Tools мне на глаза тоже не попалась. Делаю вывод, ремонт квартиры совсем меня доканал и я не врубаюсь в то, что очевидно для для остальных форумцев, которые успешно генерят себе текстовую документацию в своих проектах и в ус не дуют.
AVL, подскажите, что нужно сделать, чтобы бланк спецификации был сгенерирован с заполненными полями.

Более актуальная сборка ftp://ftp.kicad.ru/pub/kicad/install/win3...it_bin_4126.zip, рекомендую начать с нее.

К сожалению, я не писал документацию на менеджер компонентов + GOST-doc-gen.
Скорее всего прийдется это сделать.
Пока отвечаю на Ваш вопрос. По умолчанию (если Вы взяли сырую схему) все компоненты имеют не заданные поля "Наименование" (атрибут Title), ну и остальные поля тоже не заданы.
Компонент начинает отображаться в КД после того как будет задано поле "Наименование", например, Конденсатор.
Сделано так для удобства. К примеру в схеме 1000 компонентов. Вы решили поработать и назначили через менеджер компонентов параметры двухстам компонентам, и решили продолжить работать на следующий день. Вы открываете проект, смотрите какие компоненты уже имеют заданное поле "Наименование", а какие имеют пустое поле. И понимаете, что заполнять нужно дальше те компоненты, у которых поле "Наименование" пустое.
Также скоро добавлю иконки напротив каждого компонента, будет нагляднее эта логика.

Также не забывайте про пример корректно заполненной схемы demos/GOST/multivibrator.sch

Конечно же есть ряд правил как нужно работать с менеджером компонентов. Документацию делать надо.

Я использую poedit 1.4.1 в Windows. Что у Андрея не знаю, он формирует ru/kicad.po/mo.
Предложения по улучшению перевода отсылаю ему или через форум. Исходники давно не сканировал.

Проверил 1.4.1 под винду. Проблема, к сожалению, не ушла.

Проверил также версии 1.3.9, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.5.5. Безуспешно.

Сообщение отредактировал AVL - May 22 2013, 20:43

[Aldan]

Более актуальная сборка ftp://ftp.kicad.ru/pub/kicad/install/win3...it_bin_4126.zip, рекомендую начать с нее.

Скачал, установил. Если я правильно понял, то это уже третий вид нумерации сборок в дополнение к стабильной и обычным тестовым.

По умолчанию (если Вы взяли сырую схему) все компоненты имеют не заданные поля "Наименование" (атрибут Title), ну и остальные поля тоже не заданы.
Компонент начинает отображаться в КД после того как будет задано поле "Наименование", например, Конденсатор.

Да, схема у меня «сырая». Задал у нескольких компонентов в списке поле «наименование» и, о чудо, - спецификация на эти несколько компонентов сформировалась! Это вызвало необычайно бурные эмоции, т. к. наконец-то появилась эта долгожданная возможность вывода текстовой документации! ОГРОМНОЕ ВАМ СПАСИБО!
Кстати, самый первый компонент в моей схеме — кварцевый резонатор, а его в списке наименований нет. Более детальное тестирование продолжу несколько позже, т. к. мой ремонт квартиры еще не закончен, но радость от сегодняшнего события просто огромная дает стимул побыстрее его завершить!

Конечно же есть ряд правил как нужно работать с менеджером компонентов. Документацию делать надо.

Документацию никто не любит делать, это естественно, т. к. все силы и время съедает написание программы, но все же хотя бы несколько пояснительных предложений стоит сочинить, т. к. только в этом случае созданное приложение будет использоваться с максимальной эффективностью. Хорошая документация, что позолота на добротном изделии.
----------------
И еще, обычно Жан Пьер заканчивает вылизывание стабильной сборки не позже мая месяца, по крайней мере так было раньше. Так вот, возможно версия 4017 https://code.launchpad.net/~kicad-stable-co...rs/kicad/stable или какая-то ближайшая как раз этой самой наифинальной и будет. Так вот, хотелось бы иметь стабильную сборку со всеми последними усовершенствованиями в т.ч. и с генератором тектовой документации.

[AVL]

И еще, обычно Жан Пьер заканчивает вылизывание стабильной сборки не позже мая месяца, по крайней мере так было раньше. Так вот, возможно версия 4017 https://code.launchpad.net/~kicad-stable-co...rs/kicad/stable или какая-то ближайшая как раз этой самой наифинальной и будет. Так вот, хотелось бы иметь стабильную сборку со всеми последними усовершенствованиями в т.ч. и с генератором тектовой документации.

Если Вы имеете в виду попадание менеджера компонентов+GOST-doc-gen в ветку lp:kicad, то боюсь это не реально из-за серьезных разногласий с командой lp:kicad. Если будет время, почитайте, некоторая информация была озвучена на этом форуме.
В первоисточнике и в полном виде об этом можно почитать здесь:
https://code.launchpad.net/~kicad-gost-comm...d/+merge/163239
и здесь:
https://lists.launchpad.net/kicad-developers/msg10412.html

Поэтому была создана ветка lp:~kicad-gost-committers/kicad/kicad

[Aldan]

Если Вы имеете в виду попадание менеджера компонентов+GOST-doc-gen в ветку lp:kicad, то боюсь это не реально из-за серьезных разногласий с командой lp:kicad.

AVL, я, к сожалению, почти не разбираюсь в тонкостях взаимодействия стабильной ветки Кикад со всеми остальными его ветками. По жизни я вынес для себя урок: без крайней необходимости не переходить со стабильной сборки на тестовую, т. к. у меня был досадный случай некоторой порчи проекта при работе на тестовой сборке.
Вот я и стараюсь работать только на стабильных сборках, а тестовыми только иногда для тестирования пользоваться.
Видимо я наивен, т. к. до этого дня считал, что стабильная сборка — такая сборка которая приведена к максимально возможной завершенности и безглючности, т. е. «вылизанная». Если к такой сборке прикручивается некий завершенный и стабильный программный код для расширения ГОСТ-функциональности, то, весьма вероятно, что результирующий программный продукт тоже будет стабильным.
Словом, хотелось бы в обозримом будущем иметь такую стабильную сборку со всеми ГОСТ-наворотами, а не тест-сборку, дабы не наступать на старые грабли в виде порчи проекта в самый не подходящий момент.
Хочется верить, что такое пожелание не является не исполнимым и вскоре стабильная сборка «с полным фаршем» будет доступна. Иначе, я перестаю что-либо понимать в логике развития ГОСТ-Кикада - что, теперь стабильных ГОСТ-сборок никогда не будет?

[tema-electric]

стабильная сборка — такая сборка которая приведена к максимально возможной завершенности и безглючности

По опыту работы с KiCAD в 2012 году пришел к выводу, что лучше собирать тестовые сборки. Тоже верил в стабильные по началу, пока не отправил герберы с косяками в заказ ... Как мне показалось, стабильные сборки мало кто тестит. А тестовые - наоборот.

[AVL]

AVL, я, к сожалению, почти не разбираюсь в тонкостях взаимодействия стабильной ветки Кикад со всеми остальными его ветками. По жизни я вынес для себя урок: без крайней необходимости не переходить со стабильной сборки на тестовую, т. к. у меня был досадный случай некоторой порчи проекта при работе на тестовой сборке.
Вот я и стараюсь работать только на стабильных сборках, а тестовыми только иногда для тестирования пользоваться.
Видимо я наивен, т. к. до этого дня считал, что стабильная сборка — такая сборка которая приведена к максимально возможной завершенности и безглючности, т. е. «вылизанная». Если к такой сборке прикручивается некий завершенный и стабильный программный код для расширения ГОСТ-функциональности, то, весьма вероятно, что результирующий программный продукт тоже будет стабильным.
Словом, хотелось бы в обозримом будущем иметь такую стабильную сборку со всеми ГОСТ-наворотами, а не тест-сборку, дабы не наступать на старые грабли в виде порчи проекта в самый не подходящий момент.
Хочется верить, что такое пожелание не является не исполнимым и вскоре стабильная сборка «с полным фаршем» будет доступна. Иначе, я перестаю что-либо понимать в логике развития ГОСТ-Кикада - что, теперь стабильных ГОСТ-сборок никогда не будет?

Здесь могу предложить такой вариант, дожидаемся, когда менеджер компонентов+GOST-doc-gen станет "стабильным" и мержим этот код с последним стабильным релизом lp:kicad. Получаем, надеюсь, "стабильный" агрегированный релиз.

Лично я не доверяю ни тестовым релизам, ни стабильным. Причем, что кто-то несет ответственность за полную исправность стабильного релиза? Нет, это не так.
Чтобы не испортить проект платы на любом из этапов ее разработки/сохранения на диск, я пользуюсь системой контроля версий. В данный момент использую git. Если становится понятно, что что-то пошло не так, то всегда можно вернуться к предыдущему коммиту и восстановить плату в нормальном виде.
Прежде, чем отдавать плату в производство, я обязательно визуально проверяю все сгенерированные gerber-слои и файлы сверловки. Удобная для этого программа - gerbv,
В случае с KiCad, стабильную сборку не использую никогда. Иначе буду сидеть в прошлом веке. Но это не значит, что так нужно делать всем. Каждый решает для себя сам и определяется с рисками.

P.S.:
NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

На самом деле пока не видел ни одной коммерческой лицензии, где не было бы подобного отказа от ответственности.

[tema-electric]

gerbv

Когда в одной из сборок кикада в стабильную версию, да и в тестовую попали косяки с дугами при генерации герберов, то gerbv не показал косячную дугу, увы. Их показал только CAM350 и то когда уже дошло до разборок. Дуги образовывали окружность, и она была гораздо больше платы. Gerbv их просто не прорисовал, почему-то.

[AVL]

Когда в одной из сборок кикада в стабильную версию, да и в тестовую попали косяки с дугами при генерации герберов, то gerbv не показал косячную дугу, увы. Их показал только CAM350 и то когда уже дошло до разборок. Дуги образовывали окружность, и она была гораздо больше платы. Gerbv их просто не прорисовал, почему-то.

Да уж, не повезло. А KiCad GerbView тоже не показывает тот дефект?

[tema-electric]

Да уж, не повезло. А KiCad GerbView тоже не показывает тот дефект?

Смотрел. Вроде не показал тогда. Сейчас проверил - показывает. Это про кикадовский viewer.
А так я им не пользуюсь. По началу пользовался. Причина проста.
В GerbV все настроено. В файле проекта (*.gvp) достаточно поменять ручками или скриптом имена герберов. Цвета слоев и порядок уже "как надо". Сами платы предпочитаю доводить по герберам. Там меньше лишних графических элементов. В Gerbv есть кнопка обновить ... а в кикадовском вьювере помойму нет.
Имена герберов тоже в кикаде излишне подробные. Для этого скрипт написан, в стиле

Код

#!/bin/bash
# Утилита для переименовывания файлов проекта KiCAD
rename -f 's/^.*/ADigBoard.g1/gi' *VCC.gbr
rename -f 's/^.*/ADigBoard.g2/gi' *GND.gbr
rename -f 's/^.*/ADigBoard.gbr/gi' *.gbr
rename -f 's/^.*/ADigBoard.gtl/gi' *.gtl
rename -f 's/^.*/ADigBoard.gts/gi' *.gts
rename -f 's/^.*/ADigBoard.gto/gi' *.gto
rename -f 's/^.*/ADigBoard.gbl/gi' *.gbl
rename -f 's/^.*/ADigBoard.gbs/gi' *.gbs
rename -f 's/^.*/ADigBoard.gbo/gi' *.gbo

[viknn]

AVL
Gost Tools начал осваивать с конвертера библиотек и проектов Pcad. Вопросы и замечания:
1) Из файлов LIA можно получить только LIB-библиотеки kicad, а MOD?
2) Передаются параметры F0, F1, F2. Если есть F3 - например ТУ (TU) - он теряется?
3) dcm-файл можно не формировать.

[AVL]

AVL
Gost Tools начал осваивать с конвертера библиотек и проектов Pcad. Вопросы и замечания:
1) Из файлов LIA можно получить только LIB-библиотеки kicad, а MOD?
2) Передаются параметры F0, F1, F2. Если есть F3 - например ТУ (TU) - он теряется?
3) dcm-файл можно не формировать.

Ответ перенес в новую тему по pcad2kicad

Сообщение отредактировал AVL - May 24 2013, 04:45

[viknn]

AVL
А нельзя ли в GOST-doc-gen сборке реанимировать кнопку BOM (или вставить Generate BOM в Component Manager).
После работы с GOST Component Manager компоненты получают новые поля и атрибуты.
Обновленный BOM можно будет использовать разными способами. В частности,
для выпуска карт рабочих режимов ЭРИ (для аппаратуры ВН).