Tellico gère facilement et simplement les entrées avec de multiples auteurs, genres ou mots-clés et propose l'autocomplétion lors de la saisie. Les données sont sauvegardées au format XML par souci de simplicité et de ne pas dépendre d'une base de données. Il existe plusieurs filtres d'import afin de récupérer automatiquement les informations depuis le web (par exemple IMDb pour les films, Amazon pour les livres ou CDDB pour les musiques). La version 1.2, disponible depuis le 31 août, apporte la possibilité de télécharger sur kde-files.org des nouveaux masques (templates) pour entrer les données et des scripts (par exemple pour chercher les informations souhaitées sur Allocine.fr). On peut maintenant modifier facilement avec une interface graphique les couleurs et les polices de ces masques (sans avoir à toucher les fichiers XSLT). L'autocomplétion est maintenant disponible également dans les champs de filtrage. L'export HTML est également amélioré.
Le site de Tellico propose un manuel d'utilisation complet avec des captures d'écran. Vous pouvez également vous inscrire sur la liste de diffusion afin de faire passer vos souhaits à Robby Stephenson qui est le développeur principal. Il est très sympathique est il répond rapidement à chaque e-mail.
En définitive Tellico est un logiciel actuellement sans concurrence dans son genre au sein du monde du libre. Son adaptabilité et sa souplesse sont sans équivalent pour qui désire gérer simplement ses diverses collections. Il existe certe de nombreuses applications spécialisées dans un type particulier de collection (par exemple Griffith ou bien mCatalog) mais aucune n'est aussi polyvalente que Tellico.
On peut néanmoins citer GCStar (qui a été évoqué sur Linuxfr dans cette dépêche) et qui a l'ambition de proposer pour GNOME le même genre de gestionnaire universel qu'est Tellico pour l'environnement KDE. Actuellement il n'en est pas encore au même stade de développement mais c'est une application qu'il faut garder à l'½il.
Mise à jour : la version 1.2.1 de Tellico est disponible depuis aujourd'hui. Elle corrige quelques bugs et les utilisateurs de Debian ou d'Ubuntu peuvent dès maintenant télécharger les paquets sur le site de Régis Boudin.
Par exemple pour Dapper il suffit d'ajouter cette ligne dans son fichier sources.list :
deb http://www.imalip.info/tellico dapper main
Aller plus loin
- Tellico (13 clics)
- L'annonce de la 1.2 (3 clics)
# Anciennement
Posté par tuiu pol . Évalué à 4.
Quelqu'un sait pourquoi ils l'ont changé de nom ?
Excellent programme au passage..
[^] # Re: Anciennement
Posté par FRLinux (site web personnel) . Évalué à 2.
Steph
[^] # Re: Anciennement
Posté par imalip . Évalué à 8.
http://www.periapsis.org/archives/2004/09/13/renaming_bookca(...)
Et sinon c'est pas "ils", c'est "il". Robby bosse developpe Tellico tout seul (a part les quelques patches contribues, bien sur).
# problème d'installation
Posté par pada . Évalué à 4.
tellico: undefined symbol: _ZN9KLineEdit12drawContentsEP8QPainter
Oui je sais le rpm est sur cooker (2007), mais si quelqu'un sait comment réparer ça, ça me rendrait service car de mes essais c'est le logiciel le mieux adapté à une collection de musique classique et les nouveautés de cette version le rendaient encore plus attrayant pour ce genre de collection.
Autre question, est-ce qu'il reste performant avec une collection de 500 CD?
[^] # Re: problème d'installation
Posté par Mjules (site web personnel) . Évalué à 3.
[^] # Re: problème d'installation
Posté par eric63 . Évalué à 3.
Autre question, est-ce qu'il reste performant avec une collection de 500 CD?
je l' utilise pour ma bibliothèque 850 livres répertoriée avec image de couv' et résumé dégoté sur amazon avec les isbn.
Le chargement est long mais tout a fait raisonnable 1 minute environ
C' est vraiment un logiciel qui mérite le détour pour sa simplicité et les multiples possibilités offertes
[^] # Re: problème d'installation
Posté par pada . Évalué à 7.
en cherchant un peu comment faire le paramétrage, les données décivant la musique classique ne sont pas les mêmes que pour la musique pop, le compositeur n'est pas directement lié à l'interprétation ...
L'entité conceptuelle n'est plus seulement le CD mais l'oeuvre écrite par un compositeur jouée par un orchestre et quelques interprètes et qui se trouve enregistrée sur un CD, lequel CD regroupe une ou quelques oeuvres du même compositeur ou pas.
C'est un exercice de modélisation que je donne parfois à mes étudiants et qui l'échouent en général car leur modèle est celui de la musique pop. Ils comprennent alors pourquoi il est alors difficile dans bien des cas de prendre en charge ce qu'ils appellent des compils qui sont analogues à la musique classique.
# Alternatives
Posté par Mjules (site web personnel) . Évalué à 3.
http://alexandria.rubyforge.org/
Mais il est quand même loin d'égaler Tellico qui est véritablement excellent.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
# Correction
Posté par Gmooron . Évalué à 4.
GCStar fonctionne aussi sous Windows, ce qui n'est pas (encore ?) le cas de Tellico ...
[^] # Re: Correction
Posté par Tian (site web personnel) . Évalué à 1.
Du coup ca reste bien plus portable. Des utilisateurs ont même réussi à l'installer sur du MacOSX (pas en natif mais avec un serveur X).
Merci au passage à l'auteur de la news pour avoir cité GCstar qui est effectivement encore loin de Tellico. Mais j'espère que cet écart va se resserrer au fil du temps ;)
[^] # Re: Correction
Posté par 태 (site web personnel) . Évalué à 2.
Ça n'en fait pas le premier prix de portabilité : installer gnome sous macOSX est pas si compliqué que ça. Et après, installer gedit, evince, gnome-terminal se fait sans trop de difficultés.
[^] # Re: Correction
Posté par Tian (site web personnel) . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: un peu bugge cette nouvelle version 1.2.1
Posté par Robby Stephenson (site web personnel) . Évalué à 10.
(prier d'excuser mon français...)
[^] # Re: un peu bugge cette nouvelle version 1.2.1
Posté par patrick_g (site web personnel) . Évalué à 3.
Donc Billou si tu a perdu des données tu peux les récupérer dans les fichiers backup (avec l'extension ~) et installer cette nouvelle version.
Pour info le mail de Robby de ce matin :
So Tellico 1.2.1 went out the door with a bug that would cause it to use the
wrong temporary directory for writing images. So if you were opening data
files that included the images in there with them, Tellico would write
those images out to /tmp/kde-*******/tellico****** and then forget where it
put them, essentially. (KDE uses unique directory names for tmp files)
It will likely cause data loss if you save the file, and certain options are
turned on. If that happens to you, please accept my apologies. Tellico does
save backup files with the ~ extension, so look for one of those and open
it.
Tellico 1.2.2 is available with a fix. I know it’s just one day after 1.2.1
was released, and I certainly hope I don’t keep introducing bugs like this
every day. But this is an important bug fix. Version 1.2 did not have the
bug.
Robby
[^] # Re: un peu bugge cette nouvelle version 1.2.1
Posté par imalip . Évalué à 2.
[^] # Re: un peu bugge cette nouvelle version 1.2.1
Posté par patrick_g (site web personnel) . Évalué à 2.
Désolé ;-)
Je me fais l'effet d'être un vampire suçant ta bande passante...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Stockage des données...
Posté par lolop (site web personnel) . Évalué à 5.
XML est un format d'échange de données, il peut être utilisé pour exploiter en "temps réel" de petites quantités de données (surtout avec les machines actuelles), mais il n'est pas adapté à remplacer une base de données - surtout lorsque le volume stocké augmente.
Eventuellement avoir des bouts d'XML parce qu'on a des structures à stocker et qu'on a déjà les fonctions de sérialisation, mais dans un conteneur qui supporte l'indexation (du sleepycat/berkeley DB, du SQLite...).
Mais stocker en XML, dans un fichier 'plat', des données qui peuvent se montrer volumineuses et sur lesquelles on a besoin d'un accès direct: AMA non.
Un clou -> un marteau
Une vis -> un tourne-vis
On peut toujours essayer d'enfoncer une vis avec un marteau, ça marchera un peu, mais ça aura ses limites.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Stockage des données...
Posté par patrick_g (site web personnel) . Évalué à 5.
Why don't you use a real database?
Part of the reason I started Tellico was to learn C++. I didn't know SQL at the time, and at the moment, I only have a faint knowledge of how to use it. Simply put, Tellico didn't start out as a relational database, and that won't change until sometime in the future when I get around to learning SQL and have the time and motivation to change the data model. If that bothers you, well, don't use Tellico then.
Of course, anyone is welcome to make any changes they want to with the source code.
On trouve aussi cette phrase dans la présentation de Tellico sur le site :
I started developing it when I couldn't find a personal database program for KDE which didn't using a SQL backend.
J'ajoute que moi je préfère XML pour ce genre de soft. Bien entendu Tellico n'est pas fait pour stocker les 263728 Go des empreintes génétiques des citoyens du monde entier. C'est un gestionnaire de collections personnelles ! Les performances sont très correctes et en cas de besoin ou de coup dur les données XML brutes sont disponibles. C'est bien plus facile à récupérer que des données enfouies dans une base de données.
J'ai déjà entré dans Tellico plus de 1000 nouvelles de science-fiction pour mon site perso (il en reste encore au moins autant à entrer) et la rapidité du logiciel me convient tout à fait.
[^] # Re: Stockage des données...
Posté par lolop (site web personnel) . Évalué à 2.
Sauf erreur ils ont conservé une part de XML, auquel ils ont ajouté du sleepycat DB.
Mais c'est sûr qu'en cas de crash, un format XML est nettement plus facile à récupérer qu'un format binaire.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Stockage des données...
Posté par lolop (site web personnel) . Évalué à 2.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Stockage des données...
Posté par Sylvain Briole (site web personnel) . Évalué à 2.
C'est clair, mais un "dump" en SQL d'une base de données bien bâtie est aussi simple à utiliser....
[^] # Re: Stockage des données...
Posté par lolop (site web personnel) . Évalué à 4.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Stockage des données...
Posté par majordom (site web personnel) . Évalué à 1.
Mes 900 bd sont au chaud dans ce logiciel, avec les couvertures et tout et tout et tout ....
Merci encore M. Stephenson
[^] # Re: Stockage des données...
Posté par Amand Tihon (site web personnel) . Évalué à 8.
On peut toujours essayer d'enfoncer une vis avec un marteau, ça marchera un peu, mais ça aura ses limites.
Ça s'appelle enfoncer une vis à la parisienne, et c'est vraiment utilisé (dans du bois) parce qu'il y a des cas où ça tiendra mieux que si on l'avait simplement vissée. Bien sûr, ça n'est toujours pas la solution idéale. Il vaut mieux forer un avant trou et le remplir de colle avant de visser la vis.
Fin de la minute bricolage.
Il y avait longtemps que j'avais envie de réagir à cette expression, voilà une bonne chose de faite :)
[^] # Re: Stockage des données...
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: Stockage des données...
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
[^] # Re: Stockage des données...
Posté par Tian (site web personnel) . Évalué à 2.
Ca doit être dûr de mettre un coup de marteau dessus si on ne peut pas la viser...
[^] # Re: Stockage des données...
Posté par EdB . Évalué à 2.
Il faut alors des spécialistes (les couvreurs) pour persevoir ces micro déchirures et les annuler.
Donc, oui, c'est possible mais pas à la porté du simple débutant
[^] # Re: Stockage des données...
Posté par imalip . Évalué à 3.
Ca tombe bien, a l'origine Bookcase était prévu pour ce genre d'utilisation. "Collection personnelle de livres", si tu as plusieurs milliers de livres a inclure dans ta base, il y a de fortes chances pour que tu te diriges vers un autre outil, avec une vraie base de données (ou que tu en aies déja un autre).
Par la suite, ca a évolué pour gérer plus de choses ; mais revoir le coeur du soft pour utiliser un vrai systeme de base de données, c'est intrusif, ca demande du temps, surtout quand on n'a pas de connaissances en bases de données a l'origine et qu'on est tout seul.
Ca n'empeche pas Robby d'envisager l'utilisation de SQLite pour Tellico 2.0 si j'ai bien suivi ; mais pour le momen trien de commencé (tu peux quand meme proposer un patch).
Note au passage que le fait d'avoir tout en XML a part les images, ca rend les données tres simples a parser et exporter vers une vraie base de données en cas de besoin.
[^] # Re: Stockage des données...
Posté par lolop (site web personnel) . Évalué à 2.
Non, pour le moment je n'ai pas de liste... mais ça me titillerais d'en mettre une en place (CDs, DVDs, peut-être bouquins). Et là Tellico semble adapté à *mes* besoins (je suis encore dans le cas de collections raisonnables :-) ) - mais il ne faut pas sous-estimer les volumes manipulés par les collectionneurs passionnés (CDs, Timbres, cartes-postales...).
Faudra que je regarde s'il permet d'indiquer "prêté à XXX", c'est une fonctionnalité dont j'aurais besoin. ("je l'avais bien, ce DVD, où c'est qu'il est passé").
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Stockage des données...
Posté par Stop . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Stockage des données...
Posté par imalip . Évalué à 2.
Comme dit billou juste au-dessus, il y a la fonctionalité, et ca s'interface joyeusement avec le carnet d'adresses pour te laisser choisir a qui tu as preté et le calendrier KDE pour savoir quand ca a été preté et quand ca doit etre rendu.
[^] # Re: Stockage des données...
Posté par lasher . Évalué à 3.
Tu vas vexer beaucoup de chercheurs en SGBD, là. Il ne faut pas confondre la forme finale d'un document XML, le document « plat », et ce qu'est un document XML, à savoir un arbre ordonné et étiqueté. La forme finale, c'est ton fichier « lisible par un humain » (qui a pris deux-trois aspirines avant de lire le fichier de 3000 balises). Mais la base en elle-même fait exactement comme les autres : elle indexe les documents, les noeuds fils, les noeuds parents ...
« Mais stocker en XML, dans un fichier 'plat', des données qui peuvent se montrer volumineuses et sur lesquelles on a besoin d'un accès direct: AMA non. »
Du point de vue d'une BDD, un document XML est un arbre (ou un graphe, si tu utilises les IDREF - mais là t'es déjà bien vicieux ;-) ). Rien n'empêche la base d'avoir cette structure version « binaire » (structure de graphe/d'arbre donc) dans la base, et de ne dumper les fichiers XML que lorsque tu en as besoin. D'ailleurs c'est plus ou moins ce que fait BDB/XML : tu importes tes fichiers dans la base, et il garde le tout chez lui, dans une forme interne qui l'arrange. Ensuite, tu peux faire des requêtes sur la base avec XQuery, et récupérer un document au format XML en sortie.
En ce moment, beaucoup d'efforts sont fournis pour adapter les optimisations connues des SGBD/R vers les SGBD/XML. L'indexation est particulière, car si dans un SGBD/R on a des types fixes, avec des lignes de table de taille fixes elles aussi, XML est un langage semi-structuré : il faut en tenir compte.
[^] # Re: Stockage des données...
Posté par lolop (site web personnel) . Évalué à 2.
Qu'il y ait de la recherche sur des bases de données arborescente, réseau, relationnelles... on doit pouvoir a priori exporter le contenu de tous ces types de bases de données dans du XML, format d'échange suffisament riche pour pouvoir décrire diverses structures (les idrefs... pour stocker la représentation d'une base de données réseau... ça devrais le faire). J'espère que les chercheurs en bases de données ne sont quand même pas choqués quand on écrit ça.
Comme tu le dis, XML utilise des données de taille complètement variable, on peut lui coller des commentaires, des espaces en plus... ça permet peut-être à certains d'utiliser le XML comme stockage backend d'une base de données à accès direct (en stockant les index ailleurs et en donnant des offsets dans le fichier XML, les espaces/commentaires pour 'effacer' des données), mais doit se retrouver rapidement avec un gros fichier à trous (comme dans les fichiers des bases de données :-) ) qui s'éloigne rapidement de la 'beauté' d'XML liée à la capacité pour un bonzhomme d'aller directement lire le contenu.
Bref, je veux bien croire à une base de données arborescente efficace... mais pas avec XML en backend (ou alors en lecture seule et avec un ch'tit index à côté).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Stockage des données...
Posté par lasher . Évalué à 2.
L'indexation de documents XML et de leur contenu, ça existe déjà depuis un moment. Et puis, rien n'empêche au moment de l'analyse d'un fichier importé en XML de le forcer un peu à avoir une certaine gueule pour faciliter les accès dessus.
« XML ça reste du eXtended Markup Language si je ne me gourre pas - et c'est juste une normalisation du stockage "raw". »
Je ne vois pas ce que tu veux dire par là. Les SGBD/XML ont le même objectif que les SGBD/R : permettre la persistance des données. Et ne t'en déplaise, il existe déjà quelques systèmes qui permettent autre chose qu'un bête export de tables d'un modèle relationnel vers du XML (sinon, à la limite, autant exporter en CSV).
Le besoin de ce genre de SGBD vient entre autres de professions où les critères pour classifier les données sont changeants. Par exemple, une expérience faite par un labo en bio ou en chimie, et qui coûte cher - donc pas possible de recommencer tous les jours - aura tout à gagner à être stockée dans une base avec un langage semi-structuré (par ex. XML ;-) ), car au fur et à mesure qu'on aura besoin de rajouter des critères pour analyser les résultats, on pourra. Alors qu'avec un SGBD/R Classique, une fois le schéma réalisé, rajouter une colonne dans une table alors que la base est déjà en train d'être exploitée tient de la gageure.
« Après, avec une spécification de type de document (DTD & Co) on précise ce qui est acceptable pour un usage. »
Non. Avec une DTD ou un schéma XML, tu *types* ton document, et c'est ce qui fait toute la différence : on passe d'un bête fichier texte « plat » (et donc autant chercher à grands coups de regexps dessus) vers un document semi-structuré, un arbre, dont les noeuds sont ordonnés (oui, je me répète), étiquetés, et qui correspondent à des types. Et quand on a un type, on peut déjà faire tout un tas de choses.
Par exemple (on sait bien sûr aussi faire dans les SGBD/R) :
Bon ben, si j'essaie maintenant d'interroger ma base de personnes en demandant des trucs du genre
Parce que la base connaît le type des données, elle saura inférer toute seule comme une grande que l'adresse ne fait pas partie du type « identité », et la requête renverra vide.
Des choses comme ça, on sait très bien faire, et le langage XQuery est au moins aussi puissant que SQL (c'est un peu normal), voire plus.
# Cuecat
Posté par gnung . Évalué à 2.
[^] # Re: Cuecat
Posté par Xavier Maillard . Évalué à 2.
[^] # Re: Cuecat
Posté par patrick_g (site web personnel) . Évalué à 2.
Dans les notes de la version 1.2 on trouve cette phrase :
* Added parser for unmodified CueCat bar code scanner
Si c'est bien ça alors c'est vraiment cool.
[^] # Re: Cuecat
Posté par imalip . Évalué à 2.
[^] # Re: Cuecat
Posté par gnung . Évalué à 1.
1/ Ctrl+M (choisir mot-clé)
2/ tu scannes ton code à barres
3/ tout est récupéré automatiquement sut internet
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cuecat
Posté par gnung . Évalué à 1.
Il était distribué gratuitement aux US jusque dans les années 2000.
Principe de fonctionnement : tu scannais le code d'un produit dans une revue spécialisée et la connection au serveur du marchand s'effectuait automatiquement. Il a été retiré du marché car il a rapidement été détourné de son objet et qu'il a été attaqué du fait qu'il récupérait au passage tes coordonnées (remplies auparavant pour bénéficier du service); les soupçons de profilage étaient étayées :-)
Je l'utilise depuis lors avec bonheur et après une petite modification matériellle.
N'en déplaise à Xavier Maillard, il est très utile avec tellico, même si beaucoup de documents français sont inconnus des sources de données essentiellement américaines.
Voici un lien :
http://www.mavin.com/index.php?crn=188&rn=327&action=show_detail
...il a fallu quand même passer 2000 fois chez RadioSh....
[^] # Re: Cuecat
Posté par Xavier Maillard . Évalué à 1.
Je me doute bien que scanner un code à barre peut servir mais je ne voyais pas la connexion avec tellico.
Merci pour toutes ces précieuses informations en tout cas.
[^] # Re: Cuecat
Posté par thom_ra . Évalué à 1.
Quelqu'un a des pistes / adresses / URL ?
# Un oubli ?
Posté par Florian.J . Évalué à 0.
Pour une applications KDE, c'est dommage...
D'accord les jeux commerciaux natif Linux ne sont pas très nombreux, mais il y a bien MAC OS.
(J'utilise la version 1.1.6, peut etre que la 1.2 corrige cela)
# Vin
Posté par Stop . Évalué à 2.
# Bibliographie Scientifique
Posté par Darckense (site web personnel) . Évalué à 2.
Avec le champ d'URL, il permet d'ouvrir directement les fichiers PDF qui sont stockés ailleurs sur le disque.
Bon aprés, c'est sur qu'il ne s'interface malheureusement pas avec les moteurs de bibliographie scientifique, style Web of Science ou autre, mais c'est quand même le meilleur équivalent libre à EndNote que j'ai pu trouvé.
Et en plus, on peut exporter sa biblio en BibTeX...
[^] # Re: Bibliographie Scientifique
Posté par Mjules (site web personnel) . Évalué à 2.
http://jabref.sourceforge.net/
Il utilise le .bib en natif, gère les liens vers les pdf (local ou en ligne), importe un grand nombre de format, permet de rechercher et d'importer depuis pubmed et citeseer + plein d'autres trucs mais surtout, il s'interface avec lyx (et donc kile), emacs et winedit et permet d'insérer directement les références dedans.
[^] # Re: Bibliographie Scientifique
Posté par pada . Évalué à 3.
http://pybliographer.org
[^] # Re: Bibliographie Scientifique
Posté par Darckense (site web personnel) . Évalué à 2.
Les fonctionnalités m'ont l'air vraiment bien. Pourquoi ne suis-je pas tombé dessus quand je recherchais un soft de bibliographie sous Linux.
J'espère qu'il pourra importer les fichiers de Tellico. J'ai souffert quand j'ai du me tapper à la main le passage de EndNote vers Tellico...
[^] # Re: Bibliographie Scientifique
Posté par Mjules (site web personnel) . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.