Перейти к содержанию
    

KiCAD кто-нибудь использует?

Для устранения ошибки масштабирования по размеру листа при выводе на печать в pcbnew необходимо сделать исправления в файле printout_controler.cpp. Исправленный файл прилагается :rolleyes:

printout_controler.zip

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для устранения ошибки масштабирования по размеру листа при выводе на печать в pcbnew необходимо сделать исправления в файле printout_controler.cpp. Исправленный файл прилагается :rolleyes:

 

А нельзя ли это оформлять патчиками? ;) Мне не трудно самому сделать diff, но это времени займет больше.

И кого записать автором коммита? Или хотя бы кому написать "txh ..." в комментарии к коммиту?

 

ЗЫ: Проверил. При нормальном - старается размещать по центру листа.

При зеркальном - не помогло, выходит за границу. Проверял при масштабе 1.4 и 2.

Пока коммитить не буду.

 

Изменено пользователем faa

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В сборке 2011-03-29 GOST-stable заметил: при добавлении 3D-представления под виндовсом путь к нему прописывается с обратными косыми. А при сохранении эта одна обратная косая заменяется на две (и в библиотеку и в плату). При загрузке эти две косые опять превращаются в одну. Раньше раздвоения не было. И вообще - корректно ли использование в библиотеке кросс-платформенного пакета обратных косых в путях?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В сборке 2011-03-29 GOST-stable заметил: при добавлении 3D-представления под виндовсом путь к нему прописывается с обратными косыми. А при сохранении эта одна обратная косая заменяется на две (и в библиотеку и в плату). При загрузке эти две косые опять превращаются в одну. Раньше раздвоения не было. И вообще - корректно ли использование в библиотеке кросс-платформенного пакета обратных косых в путях?

В *nixaх обратная косая в тексте - это символ экранирования для следующего за ней символа. \r\n = ВК ПС, \\ = \

\\ заменяются под виндой на \, а под линухом и макосью на /.

Это позволило (наряду с указанием кодировки в файлах) читать и писать файлы на любых системах.

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

Раньше надо было перекодировать из cp1251 в utf8 и обратно, а еще и пути править - менять обратные косые на прямые и обратно (подарок вот такой от БГ).

ЕМНИП, в СР-М были прямые косые, в ДОС вдруг стали обратные. ;)

Изменено пользователем faa

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Раньше надо было перекодировать из cp1251 в utf8 и обратно, а еще и пути править
Но ведь и в предыдущих версиях кикада и в текущей винда прекрасно ест пути с прямыми косыми. Зачем было вводить эту дифференциацию? Создал файл под линухом, открыл в винде, исправил одну букву, а система контроля версий вынуждена переписывать все строки файла с путями.

 

 

И вот еще большая неприятность обнаружилась. При групповом обновлении посадочных мест (Посадочное место-> Правка->Change module(s)) компонент(ы) смещаются со своих мест в узлы текущей выбранной сетки. А еще хотелось бы чтобы при таком обновлении уже сдвинутые поля оставались на своих местах, а не прыгали в начальное положение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Раньше надо было перекодировать из cp1251 в utf8 и обратно, а еще и пути править
зачем ? не проще все писать в UTF8 ?
Теперь можно записать файл схемы, платы, библиотеки в винде и без всяких лишних телодвижений прочитать их в линухе.
в Win нормально воспринимаются пути с прямыми слешами ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И вот еще большая неприятность обнаружилась. При групповом обновлении посадочных мест (Посадочное место-> Правка->Change module(s)) компонент(ы) смещаются со своих мест в узлы текущей выбранной сетки. А еще хотелось бы чтобы при таком обновлении уже сдвинутые поля оставались на своих местах, а не прыгали в начальное положение.

С этого места поподробнее.

Какие поля? Или это модули (посадочные места)?

Компоненты (модули) были залочены?

Сетка крупнее старой?

 

 

зачем ? не проще все писать в UTF8 ?

А разве винда понимает utf8 из файла?

Сколько в ХР не открывал блокнотом файлов в утф8 - такая красота на экране получалась.

Для переноса линух-винда приходилось iconv и dos2unix/unix2dos привлекать.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

С этого места поподробнее.

Какие поля? Или это модули (посадочные места)?

Компоненты (модули) были залочены?

Сетка крупнее старой?

Да, речь о посадочных местах (и кто придумал обзывать их модулями?). Подправил, скажем, какой-то модуль в библиотеке. Хочу обновить его в плате. Выбираю Посадочное место-> Правка->Change module(s), компонент обновляется но съезжает в текущую сетку. Дорожки от него, естественно, отрываются. Компонент не залочен (заемучаешься лочить все компоненты перед обновлением, да и как-то не приходит в голову, что обновление должно включать в себя сдвиг). Сетка может быть и крупнее и мельче и вообще не кратные - скажем, расстановка в 0.635 а текущая стоит 0.5 или наоборот.

 

Поля - имеются ввиду RefDes, Value и прочие у посадочных мест. Расставил я их как мне надо для шелкографии или сборочника (как же не хватает еще пары из верхнего/нижнего неэлектрических слоев для сборочника!), потом потребовалось обновить компонент - и расставляй заново. В PCAD в этом смысле было удобно - пока не двигал поле отдельно от компонента - его положение обновляется если изменилось в библиотеке. Но если в плате что-то вручную изменил в поле - подвинул, размер шрифта поменял - все, оно больше не будет затронуто при обновлениях компонента.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А разве винда понимает utf8 из файла? Сколько в ХР не открывал блокнотом файлов в утф8 - такая красота на экране получалась.
wordpad и другие нормальные редакторы понимают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Исправил центровку при выводе на печать в pcbnew, теперь работает во всех режимах включая зеркалку. Файл printout_controler.cpp используется также и при печати в gerberview, но там вывод производится несколько иначе, поэтому я сделал изменения только для режима печати в pcbnew, а в gerberview оставил как есть. Проверял под windows. Патч прилагается, использовать так: перейти в корневой каталог сборки и запустить patch -p1 -i путь к патчу/pcbnew.patch. На всякий случай прилагаю исправленный файл.

pcbnew_patch.zip

printout_controler.zip

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Не работает :(

Вот с такими установками:

post-20394-1304402754_thumb.png

Вот прямо:

post-20394-1304402742_thumb.png

Вот зеркально:

post-20394-1304402734_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И вот еще большая неприятность обнаружилась. При групповом обновлении посадочных мест (Посадочное место-> Правка->Change module(s)) компонент(ы) смещаются со своих мест в узлы текущей выбранной сетки. А еще хотелось бы чтобы при таком обновлении уже сдвинутые поля оставались на своих местах, а не прыгали в начальное положение.

Есть такая неприятность. :(

Пофиксил в bzr2989.

А вот с полями править побольше надо - посмотрю на досуге.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Есть такая неприятность. :(

Пофиксил в bzr2989.

А вот с полями править побольше надо - посмотрю на досуге.

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

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

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

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

В этой связи вопрос к faa: планируется ли перевыпустить последний релиз после того, как замеченные баги будут исправлены?

 

------

 

Кстати, зашел сейчас на фтп Жан Пьера http://iut-tice.ujf-grenoble.fr/cao/ и вижу там 29/04/2011 kicad-2011-04-29-BZR2986-stable-UBUNTU_10.10_full_with_components_doc.tgz и KiCad-2011-04-29-BZR2986-WinXP_full_with_components_doc_install.exe. Это что, еще более новый релиз?

Так вот, все удачно и складывается: новая ГОСТ-сборка самого последнего релиза выйдет с пофиксенными багами и "усе будет у полном порядке". :-)

Изменено пользователем Aldan

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В этой связи вопрос к faa: планируется ли перевыпустить последний релиз после того, как замеченные баги будут исправлены?

Планируется в ближайшее время.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Планируется в ближайшее время.

Это добрые вести. Только, если я правильно понял, теперь планируется не перевыпуск мартовского релиза, а выпуск самого последнего релиза (если это релиз?) от 29/04/2011?

Впрочем, после выпуска сборки все будет ясно. Ждем-с :)

Изменено пользователем Aldan

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Гость
Эта тема закрыта для публикации ответов.
×
×
  • Создать...