[AVL 0]

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.

[baranovskiykonstantin 0]

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

[AVL 0]

Всем привет.

В пятницу (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 0]

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

 

Как и обещал, добавил 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 0]

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

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

Надо подумать о методе пост-копирования ru-перевода новых сообщений из новых версий развития основной ветки kicad.

Может часть сообщений, нужных только ru-сообществу, делать изначально ru.

[AVL 0]

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

 

Переименовал ветку 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

 

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

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

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

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

 

[AVL 0]

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

Да, так.

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

 

Единственное, может есть смысл все-таки оставить конструкции #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.

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

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

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

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

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

[AVL 0]

From: Барановский Константин <[email protected]>

 

Нашелся баг в 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 0]

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

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

Мне в личном письме Жан-Пьер написал такое, что существенно меняет картину по поддержке ГОСТ.

Я ему "порекомендовал" описать их намерения и видение по этому поводу публично на developer mailing list.

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

[tema-electric 0]

Собрал последнюю ревизию из репозитария 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 0]

...

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

...

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

[tema-electric 0]

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

 

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

 

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

[AVL 0]

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 файлах).