Logiciel : Dtek, nouveau logiciel de gestion de films
Posté par dtek (). Modéré le 08 décembre 2007.
DteK est un logiciel sous licence GPLv3 de gestion de films sur tout type de support. DteK est développé en Java ce qui implique que dtek peut être installé sur linux comme sous windows.
Le gros avantage de dtek par rapport à des solutions existantes (GCStar, Tellico...) c'est la possibilité de scanner votre disque dur à la recherche de vos films. DteK gère la récupération des informations techniques (Codec, BitRate, Résolution...)
Le gros avantage de dtek par rapport à des solutions existantes (GCStar, Tellico...) c'est la possibilité de scanner votre disque dur à la recherche de vos films. DteK gère la récupération des informations techniques (Codec, BitRate, Résolution...)
Site web Dtek (1013 hits)
Captures d'écran (1350 hits)
> Lire la suite (20 commentaires, moyenne: 3,4). [dépêche : 2091 caractères]
Vous avez demandé le commentaire #888787.




question du noob
Salut à tous,
J'aimerai juste savoir comment on compile ce programme qui a l'air de correspondre parfaitement à mes attentes.
Je sais à peu près faire quand il faut faire ./configure et make, mais là je ne sais pas du tout par où commencer.
Merci de m'aider !
[^]Re: question du noob
L'équivalent de make pour les applications Java est ant ( http://ant.apache.org/ ). Dans le cas de Dtek le script ant (build.xml) a été genéré avec Netbeans ( http://www.netbeans.org ) et il ne sera donc pas simple de lui spécifier les dépendances sans utiliser cet IDE. Si malgré tout tu veux le faire à la main, c'est dans le fichier nbproject/project.xml. Regarde aussi la page licence et dépendances du site web de Dtek.
Jerome
[^]Re: question du noob
Merci de ta réponse !
Effectivement, ce n'est pas simple...
J'ai d'abord du retirer une ligne de commentaire car "unmappable character for encoding UTF8" mais maintenant "cannot find symbol" une centaine de fois... Bref je m'en sortirai pas /o\
Si un généreux contributeur pouvait mettre à disportion une version précompilée et/ou un PKGBUILD pour archlinux, merci de le signaler ici !
J'espère ne pas finalement avoir à l'utiliser dans virtualbox :o)
[^]Re: question du noob
Euh, c'est du Java. Le même "binaire" fonctionne sur n'importe quelle architecture et OS à partir du moment où tu as une marchine virtuelle Java.
Si c'est juste pour utiliser le programme, c'est vraiment pas la peine de le recompiler. Évidemment le problème c'est qu'ils ne fournissent que des rpm ou des deb et pas une bête archive zip qui aurait l'avantage d'être complètement indépendante de l'architecture.
Alors soit tu parvient à décompresser le rpm ou le deb pour récupérer le résultat de la compilation, soit tu recompiles et alors il vaut mieux utiliser netbean.
[^]Re: question du noob
Youpi !
Merci pour vos conseils, j'ai réussi à bricoler qqch à partir du .deb (méthode la rache)
Quelques remarques à l'auteur s'il lit ce commentaire :
1/ c'est génial, ce logiciel propose LA fonctionnalité : chercher les films sur le disque dur
2/ MAIS il faudrait pouvoir préciser manuellement l'URL des infos du films quand le logiciel ne le trouve pas tout seul. En effet, pour certains films, (notamment avec des caractères spéciaux genre accents... mais aussi pour "Bernie" par exemple, sans que j'ai pu y trouver d'explication) le programme ne trouve pas le film dans les bases de données en ligne.
Bonne continuation et merci !
[+] [^]Re: question du noob
C'est un des soucis avec java d'avoir voulu mettre du XML un peu partout et pas toujours au bon endroit. Par exemple, dans les fichiers de conf de Tomcat et dans Ant ! Du coup, on se retrouve vite avec la dépendance sur l'IDE... Erreur de conception.
Perl a trouvé une voie que je trouve médiane en mettant ses fichiers de conf sous le format YAML. C'est facile pour la machine et c'est lisible par l'homme.
Enfin, on va avoir du mal à dévier le char d'assaut Java de sa trajectoire ;-)
[^]Re: question du noob
Euh... Je vois pas en quoi la présence du XML dans les fichiers d'Ant inclue une dépendance avec l'IDE !
Pour lire du XML avec Java, y a pas besoin d'un IDE. Et même pour exécuter un build.xml, on peut le faire à la ligne de commandes, pour autant que je sache.
[^]Re: question du noob
Exactement ! Si un build ant est bien fait, il n'est pas dépendant de l'IDE et peut être exécuté en ligne de commande (c'est même le but).
Et l'XML n'a rien à voir la dedans
Vache qui rit, à moitié dans son lit
[^]Re: question du noob
Tu peux nous expliquer en quoi mettre de l'XML dans des fichiers de config ou des scripts de build c'est mal ? Et pourquoi ça produirait une dépendance sur l'IDE ?
Parce que là je dirai plutôt erreur de compréhension de ta part que erreur de conception de Java ;-)
Vache qui rit, à moitié dans son lit
[^]Re: question du noob
A propos de la dépendance, je n'ai fait que répéter le post qui me précédait...
Je sais bien qu'un bon XML se compile avec ANT sans l'IDE. L'idée du post au dessus était de pouvoir ensuite modifier ce fichier pour le faire évoluer. Et là, il dis qu'il y a une dépendance probable sur l'IDE. Encore une fois, je ne fait que le répéter.
Sinon, si tu aimes les fichiers de conf en XML, tant mieux pour toi. J'avoue que j'ai horreur de voir un truc en XML dans mon /etc. Un fichier de conf doit rester lisible par l'Homme or le XML ne l'est pas dans la plupart des cas. D'ou ma tirade sur le YAML et le fichier de config des paquetages Perl sur le CPAN.
[^]Re: question du noob
"n fichier de conf doit rester lisible par l'Homme or le XML ne l'est pas dans la plupart des cas."
La partie en gras est la partie la plus importante de ton propos...
Un fichier XML est censé être "human-readable", s'il ne l'est pas ce n'est pas la faute du XML en soi, mais de ceux qui ont écrit la DTD.
Si certains préfèrent nommer des balises et/ou des attributs XML avec un seul caractère, c'est leur droit...
[^]Re: question du noob
Le problème n'est pas dans le seul nom des balises, il est intrinsèque au langage. Voila un exemple d'un fichier de configuration d'un module Perl pris sur le CPAN : http://search.cpan.org/src/MSERGEANT/AxKit2-1.1/META.yml
Je prends un truc écrit pour Java et Tomcat pris sur le web aléatoirement sur le site http://www.dailly.info/java/tomcat.php Cela me semble représentatif cependant de ce genre de fichier de configuration qui plus est dans un cas simple (car souvent, c'est bien plus lourd que cet exemple). Je laisse à chacun son propre jugement mais je pense personnellement que la première manière d'écrire est bien plus lisible. On sais que l'important dans ce genre de chose est la lisibilité.[^]Re: question du noob
Bizarrement une fois formaté correctement ça va mieux ...
Vache qui rit, à moitié dans son lit
[^]Re: question du noob
Tu remarqueras que j'ai cité ma source et n'est rien modifié...
Il n'empêche qu'au final, c'est nettement moins lisisble qu'un YAML car les paramêtres du système sont noyés dans du verbiage XML. Il y a beaucoup de personne ici qui aime beaucoup le Python et le YAML oblige à bien faire l'indentation comme en Python. Il faut avouer que dans ce cadre là, cela oblige à une formatage correct sinon cela ne marche pas. En YAML, les fichiers de conf doivent être lisible et éditable ligne à ligne.
web-app: servlet-name: nom_servlet servlet-class: classe_servlet servlet-mapping: servlet-name: nom_servlet url-pattern: motif[^]Re: question du noob
Je ne dis pas que YAML n'est pas clair où que l'XML doit être utilisé partout.
Simplement que XML est une alternative comme une autre et qu'il peut-être plus ou moins clair selon la manière dont il est utilisé.
Un des avantages du XML par exemple, c'est qu'il existe une tonne d'outil pour le visualiser, l'éditer, le valider, et qu'il est très facilement manipulable dans les applications.
Vache qui rit, à moitié dans son lit
[^]Re: question du noob
Il est possible de rendre plus "lisible" un document xml en utilisant un peu plus les attributs. Pour les hachages, j'utilise souvent cette forme:
Ceci dit, il y a un problème si l'on souhaite commenter les attributs. Et probablement d'autres quand on écrit la DTD.