gbirthday est un petit logiciel qui affiche une icône dans la zone de notification système pour signaler les anniversaires à souhaiter. Il est écrit en python et utilise GTK.
Il peut importer/exporter sa liste d'anniversaires depuis/vers
- evolution
- thunderbird / icedove / ligthning
- sunbird / iceowl
- une base mySQL
- un fichier CSV
Les nouveautés de la version 0.6.6 sont :
- Suppression de la dépendance historique à evolution
- Export de la liste d'anniversaires au format .ics
- Amélioration générale de l'interface, correction de bugs
Ce logiciel n'apporte pas grand chose à ceux qui sont satisfaits de leur solution intégrée de gestion de contacts et d'alarmes. Mais elle offre aux autres une solution simple et légère avec une intégration facile depuis des sources variées.
L'export en .ics permet de ne pas réinventer la roue pour gérer des alarmes.
Seules les traductions en anglais, français et allemand sont complètes.
# CardDAV
Posté par Antoine . Évalué à 4.
J'ai regardé le code source et il est très facile de rajouter un backend. C'est ce que j'ai fait pour rajouter la gestion des serveurs CardDAV. Par contre, cet accès est assez long et il n'est pas envisageable de recharger un carnet d'adresse complet à chaque démarrage. Il faudrait donc que je rajoute un cache. As-tu une préférence sur la localisation et le format de ce cache ?
Quelque chose de bizarre: lorsque je lance gBirthday, la méthode parse() de mon nouveau backend est appelé 2 fois. Une idée de la raison ?
[^] # Re: CardDAV
Posté par jihele . Évalué à 3.
Oui, il n'y a pas d'API documentée, mais quelques fonctions suffisent et sont faciles à comprendre.
Attention à une limitation que je n'ai pas évoquée dans le journal : on peut lire plusieurs carnets d'adresses, mais la fonction Add ne permet d'écrire que dans l'un d'entre eux (le premier, je suppose… personnellement, je n'utilise qu'un fichier CSV comme seule source).
Non. Enfin pour la localisation, l'idéal serait de suivre freedesktop. C'est ce que j'ai fait et j'ai mis ça dans Conf.base_data_path. Voir __init__.py :
Mon opinion vaut celle d'un autre. Le logiciel a été développé par plusieurs personnes à la suite. Lorsque j'ai proposé de modifier des choses, les anciens dévs étaient contents que quelqu'un s'y intéresse et prenne le flambeau (ce qui n'était pas mon intention…). Je suis le dernier à être intervenu mais je pense avoir fait le tour de ce que je voulais faire. Si tu veux ajouter des choses, je veux bien essayer de te conseiller, mais dis-toi que tu as le champ libre car gbirthday est un peu orphelin.
J'avais noté quelque chose dans ce goût-là en investiguant un bug pénible, mais je n'ai pas plus cherché que ça. Pour être très franc, c'est un peu un empilage de rustines, ce qui s'explique par l'historique. N'hésite pas à tailler dans le vif si tu penses que certaines choses peuvent être simplifiées. Enfin si quelque chose ne te semble pas logique, ne postule pas que tu te trompes.
# Compatible avec birthday ?
Posté par chimrod (site web personnel) . Évalué à 3.
De mon côté j'utilise birthday pour le faire.
Est-ce qu'il y a une compatibilité prévue ? Sinon je regarderais ce week-end pour ajouter le backend.
[^] # Re: Compatible avec birthday ?
Posté par jihele . Évalué à 1.
Je ne connaissais pas. Ça remplacerait gbirthday, l'interface graphique en moins.
Un backend pour gérer le format de fichier spécifique à birthday ? Non, rien de tel n'est prévu.
(En fait, rien n'est prévu du tout, à ma connaissance. A part cette histoire de pouvoir écrire dans plusieurs fichiers différents pour le même backend, qui est en suspens car faute d'en avoir besoin, personne ne s'en occupe.)
Je me demande s'il faudrait un backend supplémentaire pour ça ou bien modifier le CSV pour sa calquer sur birthday. Je dirais plutôt un supplémentaire, parce que le CSV est quand même simple à lire/écrire par un humain "normal", donc j'aimerais le conserver comme ça, et puis le format birthday n'appartient qu'à birthday et pourrait être modifié.
En tout cas, pour la lecture, ça ne doit pas être trop difficile. A noter, l'attribut can_save de la classe DataBase. Mis à False, il inhibe l'écriture, donc permet proprement de ne coder que la lecture dans un premier temps.
# Dispo dans debian sid
Posté par jihele . Évalué à 1.
Le paquet vient d'apparaître dans le dépôt unstable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.