Eric Beuque a écrit 19 commentaires

Alors pour répondre à la question on a développé ce logiciel pour répondre à plusieurs contraintes du à notre utilisation en production :
- Rapidité : Je pense que C++ reste le mieux pour créer des applications très réactive.
- Peu de dépendance : On a juste besoin de Qt, qui est fourni avec l'installeur (sous Windows et Mac). Pas besoin d'avoir Java ou Python, où une autre dépendance un peu lourde.
- Léger : Rapide à transmettre sur des postes avec une faible connexion internet.
- Multiplateforme : Besoin que ça marche sur Windows, Mac et Linux.
- Utilisable en petite résolution : On a encore du travail, mais on veut améliorer l'interface pour être utilisable en petite résolution car il nous arrive d'utiliser teamviewer, sur des postes où les résolutions sont très petites (1024x720 voir 800x600)
- On a aussi créé un code assez simple pour faciliter les éventuelles contributions

Le fait d'avoir C++ complexifie un peu le développement, mais je pense qu'il était intéressant de pouvoir proposer cet outil.

Je reconnais que le logiciel n'a pas été conçu pour ouvrir des tables lourdes. C'est pas impossible à terme. Mais il est vrai que nous n'avons pas cette problèmatique dans nos environnements c'est pourquoi cela n'a pas été un axe de développement.

Bonjour,

peut être la compilation s'est faite avec Qt4 au lieu de Qt5, du coup il manque peut être le paquet libqt4-sql-mysql

Cordialement,

La version Python que j'avais fait avait un connecteur ODBC, en revanche la version C++ ne l'a pas encore, mais c'est prévu d'être rajouté bientôt.

Après il n'est pas possible directement de faire des jointures entre les bases ouvertes dans le logiciel (sauf avec SQLite qui le permet nativement dans ses requêtes SQL).

Zut désolé :D, un bug s'était glissé dans les dernières modifications ! J'ai envoyé la correction dans le dépot.

Et j'ajouterais aussi que la dépendance à Python était problématique en terme d'installation sous Windows. Un installeur tel que nous l'avons fait actuellement facilite grandement l'installation, avec les DLL et les programmes qui va bien.

Bonjour,

en effet je ne connaissais pas ce logiciel, il a l'air très avancé et semble contenir beaucoup plus de fonction que OpenDBViewer.

Après, notre objectif à nous, est vraiment d'avoir les fonctions vitales et une facilité d'installation pour pouvoir débugger facilement même en production.

Bonjour, j'ai plusieurs raison à cela :
- de part mon travail et avec les années, je développe beaucoup sous C++ et Qt, et je suis du coup beaucoup plus à l'aise. Je maîtrise au final très peu Python.
- j'ai aussi rencontré des problèmes de performances pour la gestion des tables avec grande quantité de données (+100000 enregistrement). Problème que j'avais attribué au wrapper Qt du QTreeView et du coup, je me suis que C++ serait plus avantageux.
- comme je l'ai dit mon entreprise me permet d'avoir une chaîne de compilation avec CMake et C++ et de générer un build a chaque commit.

Voilà le pourquoi du comment ;)

Oui, à ma connaissance c'est très utilisé dans les entreprises surtout en embarqué. C'est quand même aujourd'hui un framework très complet qui permet quasiment de tout faire. Il a une grande communauté toujours disponible pour vous aider.

J'ai déjà programmé avec MFC, Qt et GTK. Je dirais de mon expérience que les avantages sont que:
- Par rapport au MFC, il a surtout l'avantage d'être multiplateforme. (Bon de toutes façon MFC, j'ai trouvé ça un peu limité et la logique un peu spécial dans certain cas).
- Par rapport à GTK, que je préfère dans certains aspects, il est pure C++ et est un poil plus léger (pas de wrapper C++ en plus). Et le fait d'être développer par une entreprise et de proposer des licences commerciales ça fait tout de suite plus "pro".

Donc pour une startup qui veut se concentrer sur le code métier de son application, Qt me parait un choix évident afin de partir sur des bases solides. Surtout depuis que la licence LGPL est disponible, qui permet de limiter l'investissement au départ.

Sait-on si la version LGPL de Qt va perdurer avec ce changement?

Cool, hésite pas à passer, on a besoin.

Ben pour le dé-entrelacement, tu peux aller chercher un paquet sur la page http://freetuxtv.eric-beuque.com/packages/ qui est compatible avec VLC 1.1 (libvlc5).

Sinon pour la séparation des chaines et des radios c pas prévu pour le moment, juste dans le but pour moi d'avoir qu'une seule liste à gérer pour me concentrer sur d'autres fonctionnalités. Mais peut être à terme...

Sinon pour les tests hésite pas a poster des bugs si tu en trouve.

Ben c'est bien ce que j'aimerai faire à peu près pour FreetuxTV, mais ça prend du temps pour en arrivé là. Mais bon a priori la programmation des enregistrements et bien prévu dans les chantiers à venir à cours terme.

En effet, FreetuxTV compil et marche sur Ubuntu Hardy avec VLC 0.8.6, je ne garanti pas par contre pas la fonction d'enregistrement, mais au moins la lecture. Malheureusement, il n'y a pas de paquets pour le moment.

myfreetv a pour le moment plus de fonction, mais l'avantage de FreetuxTV est qu'il ne nécessite pas de machine JAVA, et s'intègre bien dans les bureau Gnome.

Tu peux trouver l'adresse mail dans le menu a propos du logiciel ou sur mon site personnel.

Oui le but, ça serait de faire un truc assez général, pour être utilisé dans d'autres pays. Je sais pas si y'a d'autres service équivalent, mais si oui, le soft pourrait servir à un plus grand nombre. En attendant, il y a toujours des WebTV dans de nombreuses langues.

Pour le système communautaire c'est sur que ça serait une bonne idée, mais pour le moment j'ai beaucoup de choses à améliorer et peu de temps pour le faire, comme justement les fonctions pour l'interlace. J'avais voulu le faire pour cette version, mais j'avais plus de changement a faire que prévu, alors ça sera plutôt pour la version 0.5.0.

Shame on me. J'avoue ne connaître que les grandes lignes de chaque licence, et à l'époque où j'ai du choisir la licence quand j'ai crée le projet sur GoogleCode, j'ai pris la GPLv2 car la GPLv3 faisait encore un peu débat, me disant que ça n'était pas forcement définitif. Et du coup, c'est resté comme ça, oui peut être il temps de changer...