[Гость Guest_Aldan_*]

Может есть смысл добавить в эти библиотеки поле Title и дать ему конкретные значения прямо в библиотеке?

Например компоненту VD_DIODE_DUAL_AOA добавить поле Title Диодная сборка и т.д.

Если я не ошибаюсь, то редактор библиотек схематика имеет вкладку «описание» («правка свойств компонента» > «описание» > «описание») именно для этого. Но нужно ли ею пользоваться для достижения нашей цели?

Рассмотрим описание упомянутого компонента VD_DIODE_DUAL_AOA. Что говорит нам такая запись? «VD» говорит о том, что речь идет о диодах и все 23 разновидности их благодаря этому префиксу расположены вместе, что облегчает поиск нужного компонента из этой подгруппы при просмотре библиотеки. Далее, «DIODE_DUAL» сообщает нам о том, что это двойной диод, а « AOA» говорит о том, что на 1-й ноге анод, на 2-й катод объединенный с анодом и на 3-й другой анод.

Такая запись полностью описывает компонент, что необходимо для удобной работы разработчика с ним, но эта информация избыточна для перечня. Таким образом, подобная запись годится «и вашим и нашим». А что еще нам даст дополнительная запись в поле Title? Ничего.

Мне кажется, я понимаю, откуда у Вас появилось желание ввести еще одно поле. Наверно думается, что наличие такого спец. поля сделает возможным заполнить поле «наименование» в менеджере. Однако, Вам все равно придется стандартизировать список наименований и обрабатывать эти поля для распознавания и последующей сортировки.

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

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

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

И еще, можно сделать так, чтобы анализировалось наличие как префикса, так и поля «описание». Если префикса нет, но поле «описание» заполнено, то автозаполнение ведется на основании информации именно этого поля. Такое решение поможет промаркировать компоненты из библиотек analog_IC.lib и digital_IC.lib, которые префиксов не имеют.

Сделал в ревизии 4133.

Увы, мне доступна только сборка 4132, так что не могу это протестировать.

Кстати, правильно ли я понял, что пока что оформление штампа все еще ведется не при помощи патча Константина Барановского? Делаю такой вывод так как информация об обратном отсутствует. Что мешает внедрить патч Константина Барановского в оформление текстовых документов, чтобы все было красиво и однообразно? От кого зависит решение этого вопроса, от Вас или от Константина?

Думаю здесь потребуется пересмотр смысла полей File->Page Settings->Title Block Parameters->Title и Comment1. Считаю, что добавление окончания "Э3" в обозначении и "схема электрическая принципиальная" в наименовании правильнее делать в самой eeschema в момент отображения (чтобы сами параметры в File->Page Settings->Title Block Parameters не содержали эти окончания). Иначе придется делать некрасивое действие - удалять эти окончания в момент формирования спецификации и ПЭ3, что чревато ненадежностью как минимум.

Предлагаю в «настройки страницы» схематика в поле «наименование» ввести «нестираемую» серую надпись «схема электрическая принципиальная», которая будет автоматически отображаться вместе с названием схемы. Кроме того, в поле «децимальный номер» ввести «нестираемую» серую надпись «Э3», которая будет приписана к децимальному номеру. При таком раскладе без "серых записей" в перечень уйдет только то, что нужно и ничего не придется отбрасывать.

Жду ответ на второе письмо от Андрея Федорушкова по переводу на русский (у меня есть технические вопросы с poedit). Он сейчас пока не доступен. Как только перевод будет добавлен, данный вопрос решится сам собой.

А есть ли возможность разобраться с русификацией менеджера без помощи faa? Ведь нельзя признать удовлетворительным положение, когда судьба проекта зависит от отдельного человека. А если Андрей еще несколько месяцев не сможет ответить? Мало ли какие у него обстоятельства.

Может быть Жан Пьера насчет poedit поспрошать?

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

В прежние годы Жан Пьер прекращал вылизывание финального релиза в мае. Конечно, в этот раз все может быть иначе, но, возможно, стабильная сборка 4019 https://code.launchpad.net/~kicad-stable-co...rs/kicad/stable вышедшая в последний день мая все же финальная. В пользу данного предположения говорит еще и то, что данная сборка незамедлительно появилась на фтп Жан Пьера http://iut-tice.ujf-grenoble.fr/cao/

Так не пора ли выпустить сборку kicad_gost4019_Gdg4133_stable? (Gdg - GOST documents generator)

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

[AVL 0]

Логика удобства незаполненности полей "наименование" мне показалась сомнительной т. к. не отвечает главной цели — упрощение и ускорение генерации текстовой документации. В идеальном случае нужно достичь того, чтобы после выпуска схемы было достаточно нажать на одну кнопку и получить полный комплект текстовых документов.

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

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

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

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

Есть смысл обсуждать автоматизацию заполнения схемы.

Насчет логики незаполненности полей "Наименование" (как это сделано сейчас). Вы говорите можно делать отметку на бумаге на чем остановились при заполнении. Если говорить о заполнении по одному компоненту по порядку возрастания позиционного обозначения, да, можно было бы обходиться отметкой на бумаге. А теперь представьте другую ситуацию, заполнение выполняется групповым методом с выбором компонентов через CTRL. К примеру имеется 500 позиционных обозначений конденсаторов. 200 из них назначены групповым методом, например, назначены C1...C3, C54...C55, C81, C92, C94...C95 и т.д. Согласитесь, не удобно такое отмечать на листе бумаги.

Если рассматриваем вариант автозаполнения поля "Наименование", то я бы механизм незаполненности все-таки сохранил. Можно этот механизм незаполненности перенести в какой-то дополнительный флаг у компонента для этой цели (отвязать механизм незаполненности от поля "Наименование").

Также механизм незаполненности можно сделать включаемым/выключаемым настройкой из меню.

Если я не ошибаюсь, то редактор библиотек схематика имеет вкладку «описание» («правка свойств компонента» > «описание» > «описание») именно для этого. Но нужно ли ею пользоваться для достижения нашей цели?

Рассмотрим описание упомянутого компонента VD_DIODE_DUAL_AOA. Что говорит нам такая запись? «VD» говорит о том, что речь идет о диодах и все 23 разновидности их благодаря этому префиксу расположены вместе, что облегчает поиск нужного компонента из этой подгруппы при просмотре библиотеки. Далее, «DIODE_DUAL» сообщает нам о том, что это двойной диод, а « AOA» говорит о том, что на 1-й ноге анод, на 2-й катод объединенный с анодом и на 3-й другой анод.

Такая запись полностью описывает компонент, что необходимо для удобной работы разработчика с ним, но эта информация избыточна для перечня. Таким образом, подобная запись годится «и вашим и нашим». А что еще нам даст дополнительная запись в поле Title? Ничего.

Мне кажется, я понимаю, откуда у Вас появилось желание ввести еще одно поле. Наверно думается, что наличие такого спец. поля сделает возможным заполнить поле «наименование» в менеджере. Однако, Вам все равно придется стандартизировать список наименований и обрабатывать эти поля для распознавания и последующей сортировки.

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

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

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

И еще, можно сделать так, чтобы анализировалось наличие как префикса, так и поля «описание». Если префикса нет, но поле «описание» заполнено, то автозаполнение ведется на основании информации именно этого поля. Такое решение поможет промаркировать компоненты из библиотек analog_IC.lib и digital_IC.lib, которые префиксов не имеют.

Считаю важным сохранить возможность модификации пользователем каждого из полей, в данном случае речь о поле Title (Наименование).

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

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

Если заранее в библиотечном компоненте определять поле Title и назначать ему точное наименование согласно ГОСТ, которое и попадет в КД, не думаю, что это избыточная информация. Этой информации, с точки зрения вычислительной машины, в наличии нет.

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

С одной стороны, хранилище с библиотеками и хранилище с исходниками программы - это 2 отдельных хранилища. С другой стороны, вижу смысл делать библиотеки так, чтобы по умолчанию они были максимально совместимы с программой. Зачем их делать изначально несовместимыми?

Увы, мне доступна только сборка 4132, так что не могу это протестировать.

Кстати, правильно ли я понял, что пока что оформление штампа все еще ведется не при помощи патча Константина Барановского? Делаю такой вывод так как информация об обратном отсутствует. Что мешает внедрить патч Константина Барановского в оформление текстовых документов, чтобы все было красиво и однообразно? От кого зависит решение этого вопроса, от Вас или от Константина?

Будем делать это совместно с Константином. Нужно подождать. Сейчас не у всех есть время.

Предлагаю в «настройки страницы» схематика в поле «наименование» ввести «нестираемую» серую надпись «схема электрическая принципиальная», которая будет автоматически отображаться вместе с названием схемы. Кроме того, в поле «децимальный номер» ввести «нестираемую» серую надпись «Э3», которая будет приписана к децимальному номеру. При таком раскладе без "серых записей" в перечень уйдет только то, что нужно и ничего не придется отбрасывать.

Да, хороший вариант.

А есть ли возможность разобраться с русификацией менеджера без помощи faa? Ведь нельзя признать удовлетворительным положение, когда судьба проекта зависит от отдельного человека. А если Андрей еще несколько месяцев не сможет ответить? Мало ли какие у него обстоятельства.

Может быть Жан Пьера насчет poedit поспрошать?

Я могу уже сделать коммит с русификацией, но тогда файл kicad.po изменится примерно на 50%, а то и полностью, не смотря на добавление всего около 20 строк перевода.

В прежние годы Жан Пьер прекращал вылизывание финального релиза в мае. Конечно, в этот раз все может быть иначе, но, возможно, стабильная сборка 4019 https://code.launchpad.net/~kicad-stable-co...rs/kicad/stable вышедшая в последний день мая все же финальная. В пользу данного предположения говорит еще и то, что данная сборка незамедлительно появилась на фтп Жан Пьера http://iut-tice.ujf-grenoble.fr/cao/

Так не пора ли выпустить сборку kicad_gost4019_Gdg4133_stable? (Gdg - GOST documents generator)

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

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

То есть делать попытки стабильного агрегированного релиза все-таки надо позже.

[Aldan 0]

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

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

То есть делать попытки стабильного агрегированного релиза все-таки надо позже.

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

Здравый смысл мне подсказывает, что качественный финальный релиз может получиться только после серии тестов стабильных сборок в составе GOST-doc-gen, но, похоже, у Вас есть уверенность, что в таком тестировании нет необходимости и будет достаточно «прикрутить» отшлифованный GOST-doc-gen к финальному стабильному релизу и все будет чики-пуки. Не буду спорить, Вам виднее...

 

[AVL 0]

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

 

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

Здравый смысл мне подсказывает, что качественный финальный релиз может получиться только после серии тестов стабильных сборок в составе GOST-doc-gen, но, похоже, у Вас есть уверенность, что в таком тестировании нет необходимости и будет достаточно «прикрутить» отшлифованный GOST-doc-gen к финальному стабильному релизу и все будет чики-пуки. Не буду спорить, Вам виднее...

Их стабильные сборки все еще продолжают выпускаться.

Вести еще одну "стабильную" ветку - увеличит объем работ. Боюсь, забуксуем, если еще и ее начнем вести. И так задач уже накопилось много. Надо значит, чтобы еще кто-то подключался и помогал ;)

[faa 4]

А есть ли возможность разобраться с русификацией менеджера без помощи faa? Ведь нельзя признать удовлетворительным положение, когда судьба проекта зависит от отдельного человека. А если Андрей еще несколько месяцев не сможет ответить? Мало ли какие у него обстоятельства.

Возможность, при желании, есть. Осталость найти желающих ;)

Тут я уже, вернулся.

Пытаюсь вникнуть - столько тут понаписано за время моего отсутствия.

Обстоятельства нормальные рабочие, был в командировке.

 

[AVL 0]

Сделал русификацию менеджера компонентов в ветке lp:~kicad-gost-committers/kicad/doc

 

На реальной сборке пока не проверял.

[tema-electric 0]

Тестирую генератор перечней и спецификаций.

 

Пока теряюсь в полях. ЕСКД изучал, но по перечню ничего не помню толком, кроме ГОСТ 2.701, в котором по этому поводу тихо. Обозначение электрорадиоэлементов где-то расписано в других стандартах? Если не сложно, направьте, пожалуйста.

 

А то, например создаю резисторы, а там есть просто чипы, а есть сборки. Ну к сборкам сделал приписку в типе "Сборка". Он мне выдал в перечне:

 

Резисторы Сборка
Резисторы  
R1,R2   Сборка YC164-JR-071KL
R3        Чип 0805 3кОм 5 %
R4,R5   Чип 0805 1МОм 5 %
R6,R7   Чип 0805 3кОм 5 %
....

 

С разъемами тоже интересно. Разгруппировывает X, XT, XP, XS ... Т.е. ориентируется не на наименование "Разъем", а на префикс. Вот не знаю, правильно оно так или нет. Вроде делали всегда все в кучу.

 

Забыл еще. Александр, можно сделать так, чтобы GOST-Tools сохранял перечень или спецификацию сразу в корень проекта, или создавал там подпапку doc и в нее кидал, например, а потом открывал оттуда. А то он сейчас открывает у черта на куличиках.

 

Еще один момент. В форматках выравнивание в строках по верху, а не по центру.

[AVL 0]

Тестирую генератор перечней и спецификаций.

Пока теряюсь в полях. ЕСКД изучал, но по перечню ничего не помню толком, кроме ГОСТ 2.701, в котором по этому поводу тихо. Обозначение электрорадиоэлементов где-то расписано в других стандартах? Если не сложно, направьте, пожалуйста.

А то, например создаю резисторы, а там есть просто чипы, а есть сборки. Ну к сборкам сделал приписку в типе "Сборка". Он мне выдал в перечне:

Если речь о позиционных обозначениях, то ГОСТ 2.710-81.

Резисторы Сборка
Резисторы  
R1,R2   Сборка YC164-JR-071KL
R3        Чип 0805 3кОм 5 %
R4,R5   Чип 0805 1МОм 5 %
R6,R7   Чип 0805 3кОм 5 %
....

Хотя ГОСТ 2.710-81 прямо не описывает резисторные сборки, но там есть понятие микросборки, которые обозначаются префиксом D.

Я обозначаю резисторы с префиксом R, а резисторные сборки с префиксом DR.

С другой стороны, диоды и диодные сборки обозначаю с префиксом VD.

 

В менеджере компонентов заполняю следующим образом для Вашего примера:

1) резисторы: поле "Наименование" Резистор, поле "Тип" 0805, поле "Номинал" 3 кОм, поле "Допуск" 5%

2) резисторные сборки: поле "Наименование" Резисторная сборка, поле "Тип" YC164, поле "Номинал" 1 кОм, поле "Допуск" 5%

 

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

 

С разъемами тоже интересно. Разгруппировывает X, XT, XP, XS ... Т.е. ориентируется не на наименование "Разъем", а на префикс. Вот не знаю, правильно оно так или нет. Вроде делали всегда все в кучу.

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

Забыл еще. Александр, можно сделать так, чтобы GOST-Tools сохранял перечень или спецификацию сразу в корень проекта, или создавал там подпапку doc и в нее кидал, например, а потом открывал оттуда. А то он сейчас открывает у черта на куличиках.

Думаю можно сделать.

Еще один момент. В форматках выравнивание в строках по верху, а не по центру.

Новые форматки Константина Барановского в процессе.

[tema-electric 0]

Насчет соответствия ГОСТ здесь не помню.

Меня просто смутила строчка "Резисторы Сборка"

Александр, Вы можете сказать какие поля за что отвечают?

F0 - Позиционка

F1 - Значение

F2 - Посадочное место

F3 - вроде ссылка на документацию.

F4..

А вот остальные, которые Вы используете для хранения информации GOST-Tools, если это не сложно.

 

Вы не планируете менять расстановку полей, она конечна?

[faa 4]

Я тут выпадал из процесса на два месяца.

Может кто подскажет, когда супостаты выпилили генерацию нормального BOM в csv из eeschema?

У меня уже костыли были прикручены на перловке: из csv в tex, потом через eskdx -

на выходе готовый перечень с рамочкой.

А тут бац, и ссылка на доку с xml-ями :(

 

UPD: Нашел. Окончательно выпилили в bzr4151. Слов нет, одни буквы.

 

У меня предложение назрело:

добавить файл русского перевода в lp:~kicad-gost-committers/kicad/kicad и слегка поправить CmakeLists.txt,

чтобы он сразу добавлялся в сборку.

А из lp:~kicad-gost-committers/kicad/doc директорию internat с содержимым убрать.

 

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

И не нужно собирать дополнительно doc со всей документацией и устанавливать.

 

Изменено 10 июня, 2013 пользователем faa

[AVL 0]

Меня просто смутила строчка "Резисторы Сборка"

Александр, Вы можете сказать какие поля за что отвечают?

F0 - Позиционка

F1 - Значение

F2 - Посадочное место

F3 - вроде ссылка на документацию.

F4..

А вот остальные, которые Вы используете для хранения информации GOST-Tools, если это не сложно.

Намеренно не сделал привязку к номерам F.

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

Имена дополнительных атрибутов (помимо Reference и Value) используются следующие:

Title - Наименование

Type - Тип

SType - Подтип

Precision - Допуск

Note - Примечание

Designation - Обозначение

Manufacturer - Производитель

Вы не планируете менять расстановку полей, она конечна?

Не планировал ее делать конечной пока.

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

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

Думаю такая ситуация будет сплошь и рядом при импорте схем из других CAD.

UPD: Нашел. Окончательно выпилили в bzr4151. Слов нет, одни буквы.

В ветке lp:~kicad-gost-committers/kicad/kicad мы реанимировали BOM.

У меня предложение назрело:

добавить файл русского перевода в lp:~kicad-gost-committers/kicad/kicad и слегка поправить CmakeLists.txt,

чтобы он сразу добавлялся в сборку.

А из lp:~kicad-gost-committers/kicad/doc директорию internat с содержимым убрать.

 

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

И не нужно собирать дополнительно doc со всей документацией и устанавливать.

С одной стороны - хорошая идея.

Но вижу следующие моменты:

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

2) задумывал, что группа kicad-gost-committers ориентирована не только на русскоязычных разработчиков и пользователей, но и на интернациональных. Пока не вижу смысла не давать не русскоязычным разработчикам участвовать в этой ветке. Данная ветка - алтернатива ветке lp:kicad.

 

То есть давайте обсудим все плюсы и минусы, и решим.

 

Я бы предложил следующую схему:

1) коммитим русскоязычный перевод только в lp:~kicad-gost-committers/kicad/doc

2) изредка подтягиваем интернациональный перевод из lp:~kicad-developers/kicad/doc обратно к себе в lp:~kicad-gost-committers/kicad/doc

Изменено 10 июня, 2013 пользователем AVL

[AHTOXA 15]

1) файлы kicad.po и kicad.mo действительно меняются часто. В основном проблема с kicad.mo, это бинарный файл.

А зачем хранить в системе контроля версий бинарный файл, который однозначным образом получается из *.po? Вы же exe-шники не храните там? :)

 

Идея faa мне понравилась. Файл перевода необходим для работы программы, поэтому логично его держать вместе с ней. Ну, типа как dll.

[AVL 0]

А зачем хранить в системе контроля версий бинарный файл, который однозначным образом получается из *.po? Вы же exe-шники не храните там? :)

А правда, кто знает почему бинарные файлы kicad.mo коммитят в хранилище документации?

 

Я бы предложил следующую схему:

1) коммитим русскоязычный перевод только в lp:~kicad-gost-committers/kicad/doc

2) изредка подтягиваем интернациональный перевод из lp:~kicad-developers/kicad/doc обратно к себе в lp:~kicad-gost-committers/kicad/doc

Добавил бы еще пункт:

3) добавить сборку перевода, и возможно, документации в процесс сборки самого KiCad (в CMakeLists.txt) как предлагает Андрей. Единственное, если держать документацию и перевод в отдельном хранилище как сейчас, то в процесс сборки KiCad добавить заливку хранилища в директорию .downloads-by-cmake по аналогии как это было сделано для boost.

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

[viknn 0]

А правда, кто знает почему бинарные файлы kicad.mo коммитят в хранилище документации?

Наверно, чтобы не перепутать - видно соответствие po/mo с точностью до байта.

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

Хотелось бы, чтобы вся эта автоматика (boost/doc) не закрывала возможность после пересобирать программу в offline, если понадобится.

 

PS. Может быть в папке GOST-doc-gen наряду с шаблонами КД надо разместить и файлы шрифтов opengostfont.

Изменено 11 июня, 2013 пользователем viknn

[AVL 0]

Хотелось бы, чтобы вся эта автоматика (boost/doc) не закрывала возможность после пересобирать программу в offline, если понадобится.

При описанном подходе не должно быть разницы по сравнению со старым подходом в плане сборки в offline.

PS. Может быть в папке GOST-doc-gen наряду с шаблонами КД надо разместить и файлы шрифтов opengostfont.

Да, так и сделаем.