GRAMPS 2.0.6

Ой, как хорошо! Я как раз искал что-нибудь подобное под свои нужды. Где-то видел под винду прогу, которая отчеты создавала в виде дерева (ну такое натуральное деревцо с корнями, листьями и портретами). Здесь можно подобным образом менять вид отчета?

А для кде есть что нибудь похожее? А то влом для одной проги ставить 12 пакетов gnome-base + gnome-themes + gnome-icon-theme + еще кучу ненужного.

12 пакетов? Везет... Я вот хотел прогу это поюзать.. мне система предъявила к установке 75 пакетов... нах такое счастье...

12 пакетов. Какой ужас, это ж сколько места на винче займет. Так? Винч у меня тоже, конечно, не резиновый, но почему-то туда помещаются kdebase для tellico и gnome 1.4 для gnucash :)

Опять-таки я по заголовку догадался, чья подпись будет внизу:) Вообще, грампс - приятная штука. Жаль только, я никогда не доберусь до полноценного исследования. Времени на поездку в "глубинку" у меня точно не найдется.

apt-get -y gramps

И не смотреть на экран:)

Ну не только в пакетах дело. И интерфейсик хочется нативный.... А то GTK-проги как-то кривовато смотрятся...

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

Терпеть не могу тех, кто орет "ждем ebuild`ов"...

А потому так и не обнаружив ebuild`а для второй ветки gramps поползу сейчас писать ebuild сам... Просто о существовании второй ветки не знал и юзал первую...

Когда-то посылал им патч с лечением косяков и экспорта при работе в локали отличной от С. По моему, проигнорировали.

А вообще программа неплохая. Немного сложновата, но если приноровится, то вполне можно пользоваться. Особенно отчеты в опенофисе неплохие выводит.

Хм, Лёш, а у меня всё нормально с отчётами... И с вебовскими, и со всеми остальными.

Ну, до такой крути пока не дошли :) Хотя раз экспорт в SVG уже есть, то можно подумать над реализацией.

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

А вообще, Вам сюда: http://sourceforge.net/search/?type_of_search=soft&words=genealogy&im...

Ну с отчетами совсем нормально быть не может, поскольку в самом грампс все в utf-8, а ps или формат графа надо конвертить в однобайтную кодировку. Там у них прямо в коде была забита iso-8859-1...

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

Абстракция от тулкита - замечательная дурь.

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

Только что проверил:

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">

Ну при чем тут html?

В тех форматах, где можно использовать utf конвертации и проблем с нею нет.

Сейчас посмотрел, в графах для grphwiz так и имеем вопросики, в постскрипте - пустые места.

Латех практически сделан.

А в коде так и не повился параметр предпочтительной однобайтной кодировки. Везде iso-8859-1 так и прибит гвоздиком. Слава богу мест таких уже мало...

сам посмотри:

find /usr/share/gramps -name "*.py" | xargs grep -E "utf8_to_latin|latin_to_utf8"

и

find /usr/share/gramps -name "*.py" | xargs grep 8859

/usr/share/gramps/latin_utf8.py: return s.encode('iso-8859-1','replace') /usr/share/gramps/latin_utf8.py: return unicode(s,'iso-8859-1') /usr/share/gramps/soundex.py: strval = strval.encode('iso-8859-1') /usr/share/gramps/WriteGedcom.py:def iso8859(s): /usr/share/gramps/WriteGedcom.py: return s.encode('iso-8859-1','replace') /usr/share/gramps/WriteGedcom.py: self.cnvtxt = iso8859 /usr/share/gramps/WriteGedcom.py: elif self.cnvtxt == iso8859: /usr/share/gramps/GedcomInfo.py: f = open(filepath.encode('iso8859-1'),"r") /usr/share/gramps/docgen/PdfDoc.py: return new_s.encode('iso-8859-1') /usr/share/gramps/docgen/PSDrawDoc.py: new_text = orig.encode('iso-8859-1') /usr/share/gramps/docgen/PSDrawDoc.py: self.f.write('(%s) dup stringwidth pop -2 div '% line.encode('iso-8859-1')) /usr/share/gramps/docgen/PSDrawDoc.py: return text.encode('iso-8859-1') /usr/share/gramps/plugins/WriteGeneWeb.py: self.g.write(self.iso8859('%s\n' % (text))) /usr/share/gramps/plugins/WriteGeneWeb.py: def iso8859(self,s): /usr/share/gramps/plugins/WriteGeneWeb.py: return s.encode('iso-8859-1') /usr/share/gramps/plugins/ExportVCard.py: self.g.write('%s\n' % (text.encode('iso-8859-1')))

Вот это особенно восхищает...

/usr/share/gramps/plugins/ExportVCard.py: self.g.write('%s\n' % (text.encode('iso-8859-1')))

Вполне логично получить после этого:

Traceback (most recent call last):
File "/usr/share/gramps/plugins/ExportVCard.py", line 232, in exportData
ret = cw.export_data(filename)
File "/usr/share/gramps/plugins/ExportVCard.py", line 170, in export_data
self.write_person(key)
File "/usr/share/gramps/plugins/ExportVCard.py", line 182, in write_person
self.writeln("FN:%s" % prname.get_regular_name())
File "/usr/share/gramps/plugins/ExportVCard.py", line 154, in writeln
self.g.write('%s\n' % (text.encode('iso-8859-1')))
UnicodeEncodeError: 'latin-1' codec can't encode characters in position 3-11: ordinal not in range(256)

Хммм, Я Саше Ройтману кинул линк на это обсуждение.

ExportVCard.py Был написан парнем из Германии (Martin Hawlisch) и кроме него, по-моему, никем не используется. Очевидно, его устраивает latin1, а я, например, не пользуюс этим и понятия не имел, что за ситуация с кодировками.

НО! В отчётах (GraphViz рассмотрим отдельно, это особый случай) -- всё в utf8. PS/PDF, казалось бы, требует однобайтную кодировку. Но у нас есть gnomeprint backend, поддерживающий utf-8 PS/PDF: выбрать "Напечатать" в качетсве формата и попросить печатать в файл. Эти PS/PDF вставляют utf-8 TT шрифты в файл -- больше объём, но нет проблем с соиместимостью.

"Родные" PS/PDF всё переводят в latin1. Мы хотели их убрать, но потом решили оставить для европейских юзеров -- для latin1 достаточно дефолтных PS шрифтов.

GraphViz может использовать или PS или TT шрифт. Если выбран TT, то всё выводится в юникоде, без перекодирования. Для нормальной работы при этом нужен utf-8 TT font (FreeFonts, or ttf-freefont, or whatever it is on your system).

Шура

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

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

Причем отдельно написаны и незначительно используютсядве функции latin_to_utf8 и utf8_to_latin и параллельно iso-8859-1 забито в код.

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

Я уж не говорю о параметре кодировка в диалоге экспорта.

Согласен, конвертация используется нехорошо, не в одном месте, и т.д. Я просто хотел подчеркнуть, что это происходит в редких местах (plugins), в основном потому, что plugins пишутся разными людьми в разное время. Что не меняет сути дета, я согласен.

Параметр кодировки в диалоге экспорта есть в GEDCOM, а в остальные экспортёры его надо добавить. Пришли(те), пожалуйста, патч если у тебя (Вас) есть время :-) К стыду своему, не помню, чтобы кто-то присылал патчи на эту тему. gramps-devel@lists.sf.net или bug report with the tracker at http://sf.net/projects/gramps