LINUX.ORG.RU
Форум — Desktop  

Обсуждение редактора контактов DoubleContact

 , , ,


7

6

Тема создана для обсуждения DoubleContact — кроссплатформенного редактора/менеджера контактов для ПК. Программа написана на языке C++ с применением фреймворка Qt (минимальная версия Qt — 4.8, рекомендуемая — 5.10 и выше) и распространяется по лицензии GPLv3+.

Автор также планирует помещать здесь анонсы минорных версий DoubleContact, не заслуживающих новостей на главной.

На данный момент актуальная версия программы имеет номер 0.2.4 и работает с локальными адресными книгами. К ветке 0.4 планируется добавление работы с телефонами (ADB и др.), к ветке 0.5 — работа с сетевыми протоколами.

Github

Русский сайт автора

Архив новостей и форумных тем на ЛОРе

★★★★★

Последнее исправление: hobbit (всего исправлений: 5)
  1 2 3 →
Ответ на: комментарий от dataman

Хотелось бы, чтобы при двойном клике по группе, она переносилась из списка «Доступные группы» в «Контакт в группах». И наоборот.

Сделал.

hobbit ★★★★★
() автор топика
25 июня 2024 г.

На Debian 12 как-то так:

eugrus@eugensdebianpc:~/Загрузки$ sudo dpkg -i doublecontact_0.2.4-buster_amd64.deb 
[sudo] пароль для eugrus: 
Выбор ранее не выбранного пакета doublecontact.
(Чтение базы данных … на данный момент установлено 871029 файлов и каталогов.)
Подготовка к распаковке doublecontact_0.2.4-buster_amd64.deb …
Распаковывается doublecontact (0.2.4) …
dpkg: зависимости пакетов не позволяют настроить пакет doublecontact:
 doublecontact зависит от libqtcore4 (>= 4.8), однако:
  Пакет libqtcore4 не установлен.
 doublecontact зависит от libqtgui4 (>= 4.8), однако:
  Пакет libqtgui4 не установлен.

dpkg: ошибка при обработке пакета doublecontact (--install):
 проблемы зависимостей — оставляем не настроенным
Обрабатываются триггеры для mate-menus (1.26.0-3) …
Обрабатываются триггеры для desktop-file-utils (0.26-1) …
Обрабатываются триггеры для gnome-menus (3.36.0-1.1) …
Обрабатываются триггеры для mailcap (3.70+nmu1) …
При обработке следующих пакетов произошли ошибки:
 doublecontact
eugrus@eugensdebianpc:~/Загрузки$ sudo apt install libqtcore4 libqtgui4
Чтение списков пакетов… Готово
Построение дерева зависимостей… Готово
Чтение информации о состоянии… Готово         
Пакет libqtcore4 недоступен, но упомянут в списке зависимостей другого
пакета. Это может означать, что пакет отсутствует, устарел или
доступен из источников, не упомянутых в sources.list
Однако следующие пакеты могут его заменить:
  qtchooser:i386 libqt5core5a:i386 qtchooser libqt5core5a

Пакет libqtgui4 недоступен, но упомянут в списке зависимостей другого
пакета. Это может означать, что пакет отсутствует, устарел или
доступен из источников, не упомянутых в sources.list

E: Для пакета «libqtcore4» не найден кандидат на установку
E: Для пакета «libqtgui4» не найден кандидат на установку
eugrus@eugensdebianpc:~/Загрузки$ sudo apt install libqt5core5a
Чтение списков пакетов… Готово
Построение дерева зависимостей… Готово
Чтение информации о состоянии… Готово         
Уже установлен пакет libqt5core5a самой новой версии (5.15.8+dfsg-11).
libqt5core5a помечен как установленный вручную.
Вы можете запустить «apt --fix-broken install» для исправления этих ошибок.
Следующие пакеты имеют неудовлетворённые зависимости:
 doublecontact : Зависит: libqtcore4 (>= 4.8) но он не может быть установлен
                 Зависит: libqtgui4 (>= 4.8) но он не может быть установлен
E: Неудовлетворённые зависимости. Попытайтесь выполнить «apt --fix-broken install», не указывая имени пакета (или указав решение).
eugrus@eugensdebianpc:~/Загрузки$ sudo apt install qtchooser
Чтение списков пакетов… Готово
Построение дерева зависимостей… Готово
Чтение информации о состоянии… Готово         
Уже установлен пакет qtchooser самой новой версии (66-2).
qtchooser помечен как установленный вручную.
Вы можете запустить «apt --fix-broken install» для исправления этих ошибок.
Следующие пакеты имеют неудовлетворённые зависимости:
 doublecontact : Зависит: libqtcore4 (>= 4.8) но он не может быть установлен
                 Зависит: libqtgui4 (>= 4.8) но он не может быть установлен
E: Неудовлетворённые зависимости. Попытайтесь выполнить «apt --fix-broken install», не указывая имени пакета (или указав решение).
eugrus@eugensdebianpc:~/Загрузки$ sudo apt --fix-broken install
Чтение списков пакетов… Готово
Построение дерева зависимостей… Готово
Чтение информации о состоянии… Готово         
Исправление зависимостей… Готово
Следующие пакеты устанавливались автоматически и больше не требуются:
  libwpe-1.0-1 libwpebackend-fdo-1.0-1
Для их удаления используйте «sudo apt autoremove».
Следующие пакеты будут УДАЛЕНЫ:
  doublecontact
Обновлено 0 пакетов, установлено 0 новых пакетов, для удаления отмечено 1 пакетов, и 11 пакетов не обновлено.
Установлено или удалено не до конца 1 пакетов.
После данной операции объём занятого дискового пространства уменьшится на 7 631 kB.
Хотите продолжить? [Д/н] y
(Чтение базы данных … на данный момент установлено 871078 файлов и каталогов.)
Удаляется doublecontact (0.2.4) …
Обрабатываются триггеры для gnome-menus (3.36.0-1.1) …
Обрабатываются триггеры для mate-menus (1.26.0-3) …
Обрабатываются триггеры для mailcap (3.70+nmu1) …
Обрабатываются триггеры для desktop-file-utils (0.26-1) …
eugrus ★★★★★
()
4 сентября 2024 г.
8 октября 2024 г.

По итогам недавних обсуждений (раз, два) добавил в исходники работу с CSV-файлами, созданными в Sylpheed (3.7.0+). Поддерживается чтение и запись, разделитель-запятая (работу с разделителем-табуляцией добавить можно, но я пока не уверен, нужно ли).

Sylpheed сохраняет один контакт с несколькими почтами как несколько CSV-записей. Автообъединение при импорте сделать можно, но у него с большой вероятностью будут ложные срабатывания. Поэтому я лучше починю склеивание контактов, выделенных пользователем (только что обнаружил, что оно работает не совсем так, как я ожидал, надо разбираться). В качестве альтернативы этому CSV можно было бы добавить и поддержку XML-файла от Sylpheed, там почты структурированы по контактам. Но это, если честно, внутренний формат, нет гарантии, что завтра сильфидовцы не поменяют его или вообще не заменят на какой-нибудь .sqlite.

Из курьёзов: при чтении CSV собственного формата Sylpheed понимает заголовок и предлагает упорядочить по его полям… после чего добавляет этот заголовок в адресную книгу в качестве одной из записей. Не смертельно.

Нововведения пока в мастере на гитхабе, чуть позже сделаю сборку…

hobbit ★★★★★
() автор топика
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

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

А хотя нет. Если выделить 2 контакта с разными почтами и вызвать Join/Склеить, оно покажет диалог слияния и подсветит поля с почтой. Если после этого нажать самую правую кнопочку со стрелкой влево, в объединённом контакте будут обе почты.

Так что – нормально, этим можно пользоваться. И это более предсказуемо, чем автоматическое объединение, поскольку находится под контролем пользователя.

hobbit ★★★★★
() автор топика
Последнее исправление: hobbit (всего исправлений: 2)
8 ноября 2024 г.

Предлагаю для тестирования экспериментальную статическую Linux-сборку DoubleContact, которая теоретически должна работать с любыми относительно современными (условно говоря, 6 лет и моложе) дистрибутивами на архитектуре x86_64. Собрана на Ubuntu 18.04 и статической сборке Qt 5.12.12. Я проверил её на Debian Buster, Fedora 35 (старая, да) и Manjaro KDE (этот, наоборот, с последними обновлениями).

На текущий момент сборка распространяется в виде архива tar.xz (вот прямая ссылка на гитхаб) и требует рута (всё копируется в /usr). Для последующего удаления можно использовать скрипт remove-doublecontact-root-build (есть в архиве).

Разумеется, это времянка для энтузиастов, следующим шагом будет обернуть это всё в AppImage. Но это следующий шаг, сейчас хотелось бы прощупать жизнеспособность самой сборки. Пишите, что заработало, что не заработало, и главное – что у вас за дистрибутивы и каких версий. Версия программы условно обозначена как 0.2.5 beta 1.

hobbit ★★★★★
() автор топика
Ответ на: комментарий от hobbit

распространяется в виде архива tar.xz

Извлёк только бинарник doublecontact в директорию с архивом. После запуска:

  • выводится предупреждение «Language list loading error»
  • пустой тулбар под меню.
dataman ★★★★★
()
Ответ на: комментарий от dataman

Извлёк только бинарник

выводится предупреждение «Language list loading error»

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

Логика такая: если он запущен из /usr/bin, то лезет за переводами и их списком в /usr/share/doublecontact/translations, а если нет – то в ../translations либо в ../../doublecontact/translations. Кстати, куда он лезет по умолчанию, можно посмотреть, открыв окно About и заглянув на вкладку Additional/Дополнительно.

пустой тулбар под меню.

Он по жизни пустой, не только в статике. Его да, надо бы наполнить, но тут вопрос упирается в рисование подходящих иконок или поиск оных под подходящей лицензией. Я не художник, может, кто-нибудь подсобит? (И спасибо за напоминание, это неплохо бы сделать до выпуска версии 0.3.)

Остальное-то работает? VCFы открываются? И хотелось бы узнать, что за дистрибутив.

hobbit ★★★★★
() автор топика
Последнее исправление: hobbit (всего исправлений: 3)
Ответ на: комментарий от dataman

Вот нашёл комментарий на хабре, где автор пришёл к тем же выводам, что и я.

Комментарий 2013 года, но боюсь, что с тех пор если что и изменилось, то в худшую сторону. Не то, чтоб я совсем отвергаю поддержку cmake (недоделанный CMakeLists у меня не просто так оставлен), но сейчас это совершенно точно не высокоприоритетная задача.

hobbit ★★★★★
() автор топика

Накидал тут небольшой PKGBUILD-ик для программы. Ну как, годится? :) Собирает он как раз 0.2.5b1. И патчик:

$  cat build/doublecontact/copy-documentation-recursively.patch 
--- make-bin-image	2024-11-11 20:16:50.672376166 +0300
+++ make-bin-image.new	2024-11-11 20:33:31.306839067 +0300
@@ -24,6 +24,6 @@
 cp /usr/share/qt${QT_MAJV}/translations/qt_??_??.qm ${TRANS_PATH}/
 cp ${SRC_DIR}/app/doublecontact.desktop ${DSK_PATH}/
 cp ${SRC_DIR}/img/32x32/doublecontact_32x32.xpm ${IMG_PATH}/
-cp ${SRC_DIR}/doc/* ${DOC_PATH}/
+cp -r ${SRC_DIR}/doc/* ${DOC_PATH}/
 cp ${SRC_DIR}/COPYING ${DOC_PATH}/
 cp ${SRC_DIR}/README.md ${DOC_PATH}/

А то без -r документация не копируется.

yars068 ★★★★
()
Последнее исправление: yars068 (всего исправлений: 2)
Ответ на: комментарий от hobbit

Да, можно было и имеющийся приспособить под новую версию, да и написан он более правильно, чем мой. Но раз версия программы тестовая, сойдет :) И вопрос, а зачем вот эти две строчки в скрипте?

cp /usr/share/qt${QT_MAJV}/translations/qt_??.qm ${TRANS_PATH}/
cp /usr/share/qt${QT_MAJV}/translations/qt_??_??.qm ${TRANS_PATH}/

Разве при сборке файлы переводов не остаются в дереве исходных файлов?

yars068 ★★★★
()
Последнее исправление: yars068 (всего исправлений: 1)
Ответ на: комментарий от hobbit

Тогда, по моему мнению, более правильным было бы тащить в зависимостях qt5-translations (название пакета арчеспецифичное). Если эти файлы пакуются в пакет из системы, на которой ведется сборка, получается, что этот пакет так и так должен стоять.

yars068 ★★★★
()
Ответ на: комментарий от yars068

Я долго тупил, пытаясь вспомнить, в чём там глубокий смысл, наконец, догадался глянуть в собственные исходники и вспомнил. :)))

Логика такая. У программы есть каталог с переводами, путь к которому формирует функция LanguageManager::transPath(). Сейчас там лежат переводы как самого doublecontact, так и общекутешные.

И есть как минимум две ситуации, в которых это логично:

  1. сборки для ОС, в которых Qt не подтягивается для пользователя пакетным менеджером (как минимум, винда и макось);
  2. универсальные дистронезависимые сборки для линукса, не зависящие от пакетов с Qt (тот же AppImage, например).

А вот при традиционном опакечивании в deb/rpm/etc с применением «системной» Qt это, наверное, плохая идея, поскольку условный qt_ru.qm лежит как в каталоге с Qt, так и в каталоге с программой. Сам по себе он очень маленький (буквально полторы сотни байт на 1 язык), но когда пакет тащит несколько десятков языков, а кутешных программ в установленной системе много, это уже начинает огорчать и намекать на несовершенство нашего мира. :)

Возможно, стоит подумать о разделении на собственно transPath и qtTransPath. Первый всегда связан с программой, а второй в зависимости от сборки может указывать и на кутешный каталог. И подтягивать для арча qt5-translations, для дебиана qttranslations5-l10n, для других дистров аналогично.

Подумаю.

P.S. А с третьей стороны, я сейчас глянул содержимое этого самого qttranslations5-l10n, там что-то дофига всего, что пользователю не нужно, файлы справки, например. Так что может быть, существующий вариант и оптимален.

P.P.S. Другое дело, что в качестве источника копирования, получается, не всегда выступает /usr/share/qt?/translations/, как раз при статической сборке, где это копирование нужно в первую очередь, оно идёт каким-нибудь developer-префиксом. И вот это я, пожалуй, поправлю в ближайшее время…

hobbit ★★★★★
() автор топика
Последнее исправление: hobbit (всего исправлений: 2)

Принял PR от @u-235, актуализирующий поддержку cmake. Заявлена поддержка Qt 4,5,6. Сразу скажу, с Qt6 не проверял, там пока возможны баги с самим моим исходником. С более старыми мажорными версиями проверил, работает.

hobbit ★★★★★
() автор топика
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

Для Qt6 пришлось частично комментировать участки кода с QTextCodec и в паре мест делать условную компиляцию, поэтому о полноценной проверке сборки с Qt6 пока сказать нельзя.

anonymous
()
  1 2 3 →
Desktop