Petite correction : ics n'est disponible qu'en export. L'idée est de générer un fichier .ics qui peut être sourcé dans un calendrier tiers pour affichage et éventuellement alarmes, par exemple chez moi dans Orage (Xfce). J'ai ajouté la possibilité de mettre des champs personnalisés parce que par exemple Orage utilise des champs à lui pour définir le mode de notification des alarmes, par exemple.
(Attention, l'alarme créée déclenche un bug d'Orage <= 4.8.3.1 dont la correction n'est peut-être pas encore intégrée dans toutes les distributions. Rassurez-vous c'est intégré dans Debian Wheezy.)
Pourquoi gbirthday
Pour la petite histoire, j'ai commencé à regarder vers gbirthday parce que j'oubliais trop d'anniversaires, et je n'étais pas enchanté par les systèmes tout-en-un. Chez moi c'est Xfce, et je n'arrivais pas à faire fonctionner les alarmes d'Orage. D'une manière générale, je n'utilise pas trop Orage pour m'organiser.
Et surtout, les anniversaires ont quelque chose de spécifique. Je veux les voir à l'avance (penser à un cadeau ?), savoir quand ça se rapproche (et si je n'étais pas là le jour même ?) et éventuellement quand c'est passé. Ce n'est pas tout à fait pareil qu'un rendez-vous ordinaire (ça se discute, surtout un vendredi, mais c'est mon expérience utilisateur).
Je comprends tout à fait que les utilisateurs d'environnement où tout est intégré ne voient pas trop l'intérêt. J'avais hésité à une époque à modifier Orage au lieu d'utiliser gbirthday, mais ça me semblait plus compliqué.
Le développement
gbirthday est un truc tout petit, à côté. C'est, je crois, un gars qui est parti de l'exemple de GtkStatusIcon pour afficher les anniversaires depuis évolution, puis un autre qui a ajouté le support pour une autre source, etc.
Il n'y a pas de développement de prévu pour le futur. Certains anciens développeurs ne l'utilisent plus. Les autres sont contents de l'état actuel.
Mais rien n'empêche quiconque de proposer une fonctionnalité supplémentaire, un backend, etc. C'est le sens de mon appel pour l'Application Indicator, et les autres contributions sont aussi bienvenues.
L'API pour les backends n'est pas documentée, mais ça ne doit pas être trop dur à comprendre.
Côté architecture, c'est pour des raisons historiques assez rustiné, donc il ne faut pas s'étonner si par moment c'est inutilement tordu…
# Précisions / suppléments
Posté par jihele . En réponse à la dépêche Présentation de GBirthday et appel à contribution. Évalué à 5.
Merci Florent pour la dépêche.
ICS
Petite correction : ics n'est disponible qu'en export. L'idée est de générer un fichier .ics qui peut être sourcé dans un calendrier tiers pour affichage et éventuellement alarmes, par exemple chez moi dans Orage (Xfce). J'ai ajouté la possibilité de mettre des champs personnalisés parce que par exemple Orage utilise des champs à lui pour définir le mode de notification des alarmes, par exemple.
(Attention, l'alarme créée déclenche un bug d'Orage <= 4.8.3.1 dont la correction n'est peut-être pas encore intégrée dans toutes les distributions. Rassurez-vous c'est intégré dans Debian Wheezy.)
Pourquoi gbirthday
Pour la petite histoire, j'ai commencé à regarder vers gbirthday parce que j'oubliais trop d'anniversaires, et je n'étais pas enchanté par les systèmes tout-en-un. Chez moi c'est Xfce, et je n'arrivais pas à faire fonctionner les alarmes d'Orage. D'une manière générale, je n'utilise pas trop Orage pour m'organiser.
Et surtout, les anniversaires ont quelque chose de spécifique. Je veux les voir à l'avance (penser à un cadeau ?), savoir quand ça se rapproche (et si je n'étais pas là le jour même ?) et éventuellement quand c'est passé. Ce n'est pas tout à fait pareil qu'un rendez-vous ordinaire (ça se discute, surtout un vendredi, mais c'est mon expérience utilisateur).
Je comprends tout à fait que les utilisateurs d'environnement où tout est intégré ne voient pas trop l'intérêt. J'avais hésité à une époque à modifier Orage au lieu d'utiliser gbirthday, mais ça me semblait plus compliqué.
Le développement
gbirthday est un truc tout petit, à côté. C'est, je crois, un gars qui est parti de l'exemple de GtkStatusIcon pour afficher les anniversaires depuis évolution, puis un autre qui a ajouté le support pour une autre source, etc.
Il n'y a pas de développement de prévu pour le futur. Certains anciens développeurs ne l'utilisent plus. Les autres sont contents de l'état actuel.
Mais rien n'empêche quiconque de proposer une fonctionnalité supplémentaire, un backend, etc. C'est le sens de mon appel pour l'Application Indicator, et les autres contributions sont aussi bienvenues.
L'API pour les backends n'est pas documentée, mais ça ne doit pas être trop dur à comprendre.
Côté architecture, c'est pour des raisons historiques assez rustiné, donc il ne faut pas s'étonner si par moment c'est inutilement tordu…