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

Установил новую виртуалку с 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 - собралась и работает.

Всем привет.
В пятницу (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 секции.

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

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

Как и обещал, добавил 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?
Либо может есть другой вариант как поступить с документацией?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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