Discussion :

[thom_yorke_59]

Bonsoir à tous,

L'un de mes amis a développé un superbe logiciel permettant de gérer ces cartes à collectionner (WoW, Magic, Yu-Gi-Oh), ainsi que la gestion des deck. Le développement a été fait en Python, avec une interface en TCL et les données sont stockées dans différents fichiers textes à plat. Dernier point, c'est portable et multi-plateforme (pas besoin d'installer plein de framework, ça fonctionne tout seul, le pied ).

Concrètement, ça claque Toutes les fonctions sont disponibles, mais il faut bien l'avouer, l'interface en TCL a pris un sacré coup de vieux, quand on voit ce que l'on a ailleurs.

L'ami n'étant pas motivé pour redévelopper ce logiciel, je me suis proposé. Bye bye la V1, Welcome la V2

Exit le python, le TCL et les fichiers textes à plat, j'ai parcouru les différents forums et il semblerait que le duo C++ / Qt avec un base en SQLite serait une bonne alternative. Sachant, que le java, je peux pas le blairer

Et j'en arrive à ce stade, pensez-vous que ce duo est une bonne solution ? Sinon, pourriez-vous m'en proposer d'autre ? Sachant que s'il fallait partir sur un nouveau langage, je ne suis pas réfractaire en l'apprendre.

Merci à tous pour votre aide

Bye

[nikko34]

Si c'est juste l'interface graphique vous pouvez pas juste changer de librairie d'interface graphique? En imaginant que le code est décorrélé de l'interface, ce qui n'est peut être pas gagné

[thom_yorke_59]

C'est une possibilité effectivement. Mais après avoir vu le code source... comment dire... je préfère repartir de zéro

Et puis, il y a aussi le fait qu'il utilise des fichiers textes à plat pour les données. Donc il faudrait également réécrire cette partie.

Donc au final, je repars du début. Nouveau langage, nouvelle interface, nouvelle gestion des données.

[Mac LAK]

J'aurais tendance à partir sur une solution RAD, pour ma part, mais sinon il faudrait savoir ce que tu cherches à privilégier :

• La portabilité ?
  Sachant que c'est bien joli sur le papier mais qu'il faut quand même le tester, le vérifier, le maintenir et que si personne ne l'utilise sur autre chose qu'un Windows (ou un Linux), ça ne sert à rien de le faire en mode portable...
• La vitesse de développement ?
• La vitesse d'exécution ?
• La possibilité de changer à loisir l'interface graphique et/ou le stockage et/ou le moteur ? Donc la maintenabilité ?
• Le fait d'apprendre quelque chose de nouveau ?
• Obiwan Kenobi ?

Si tu précises un peu mieux le(s) point(s) le(s) plus important(s) pour toi, il sera plus facile de te conseiller.

Et ne dis pas "tous", ça n'aidera pas...

[thom_yorke_59]

Voici les besoins par ordre de priorité :
* Portabilité : Windows/Linux... Le reste n’est pas très utile
* Maintenabilité : mais c’est surtout une question de style d’écriture de code. Un logiciel maintenable est un logiciel qui évolue et qui donc ne meure pas
* Vitesse de développement

Et j'oubliais, le joker Obiwan Kenobi, sans qui le développement serait plus long que prévu (à défaut de Chuck Norris)

[eyquem]

Bonjour,



Quand tu écris « Concrètement, ça claque » , que veux tu dire, stp ?



Ce que tu exposes m’intéresses. J’espère que tu nous informeras de temps à autre de la progression de ton projet.



Je suis curieux sur quelques points:

Exit le python, le TCL et les fichiers textes à plat

TCL et fichiers à plat, je comprends pourquoi.
Mais quelle est la raison de ne pas faire la version en Python ? Parce que tu ne connais pas ce langage ?

après avoir vu le code source... comment dire... je préfère repartir de zéro

Ça me semble plus raisonnable, même sans avoir vu le code.
Mais qu’est ce qu’il a justement ce code ? On pourrait en voir un bout ? Il est long ?

Et puis, il y a aussi le fait qu'il utilise des fichiers textes à plat pour les données. Donc il faudrait également réécrire cette partie.

Quel est le rapport entre les fichiers à plat et l’obligation de changer de langage ?
Il me semble mieux d’abandonner les fichiers à plat, quel que soit le langage qui sera utilisé.
Est-ce à dire que tu as choisi de mettre les données dans une Base de Données ? Ou cherches tu encore par quoi tu vas remplacer les fichiers à plat ?
Je te signale que Python dispose de plusieurs modules pour la persistance de données sans recourir a une BD:
http://docs.python.org/library/persistence.html

Maintenabilité : mais c’est surtout une question de style d’écriture de code.

bof..... quand je parcours le forum C++, j’ai bien l’impression que c’est aussi et surtout une question de langage. Le style dans lequel on écrit un code étant quand même fort contraint dans les limites que pose le style propre du langage utilisé, uh ?









Une quetion à Mac LAK:

La possibilité de changer à loisir l'interface graphique et/ou le stockage et/ou le moteur ? Donc la maintenabilité ?

Dans ton esprit, cette possibilité est-elle dépendante du langage ?
Ne dépend elle pas surtout de l’algorithme qui va charpenter le code de façon modulaire ou non ?

[Mac LAK]

Dans ton esprit, cette possibilité est-elle dépendante du langage ?

Elle dépend en partie du langage, dans le sens où certains "poussent" à entremêler IHM et traitement fonctionnel. Mais surtout, il n'y a parfois pas le choix (suivant le langage) du framework à utiliser, ce qui pose problème si l'on veut pouvoir le faire.
Pour le stockage, de la même manière, tu peux avoir des solutions "natives" au langage qui sont plus pratique et/ou plus rapides à utiliser, mais bloquer du même coup la possibilité de changer de moteur de stockage.

Ne dépend elle pas surtout de l’algorithme qui va charpenter le code de façon modulaire ou non ?

Bien sûr : il faut décorréler le code fonctionnel, la gestion de l'IHM et le stockage pour pouvoir changer librement chaque couche.

Mais ça ne sert à rien de se casser la tête à le faire si tu n'as pas le choix du framework graphique par contrainte de langage, ou que tu ne peux t'interfacer qu'avec une seule sorte de BD...

[eyquem]

Merci Mac LAK. Voilà une réponse qui cLAK (= efficace).



Je ne connais que Python.

Pourrais tu indiquer pour les langages que tu connais si chacun laisse la liberté du choix d’un IHM ou non, et d’une BD ou non.

[thom_yorke_59]

Si on peut réutiliser le langage python mais avec une bibliothèque graphique, genre QT, oui pourquoi pas... Bon j'ai fais une petite recherche sur le Net et effectivement c'est possible. Idem, entre Python et SQLite.

Bon, je pense que je vais rester sur du python alors.

[eyquem]

Si je comprends bien les choses que je lis sur le web, Tcl n’est pas un GUI mais un langage de script.
Ton projet consiste donc à passer d’une interface non-GUI (Tcl) à une interface graphique (si l’on prend le Qt dont tu parles comme signifiant que tu veux une interface graphique).



Or Tkinter, la bibliothèque graphique libre d'origine de Python, est une adaptation de la bibliothèque graphique Tk écrite à l’origine pour Tcl.
Il faut examiner si cette bibliothèque ne pourrait pas te suffire et si, vu son lien avec Tcl, elle ne pourrait pas faciliter ton développement.



Mais Tkinter est une vieille interface graphique que beaucoup trouvent dépassée.
Il est souvent question dans les posts de pythonistes que je lis comme bibliothèque graphique plus moderne de wxPython qui semblent donner toute satisfaction.



Autre bibliothèque graphique utilisable avec Python: PyQt



Des forums consacrés à ces bibliothèques graphiques se trouvent là:
http://www.developpez.net/forums/f16...thon-zope/gui/



Il existe aussi PyGTK qui a un sous-forum dans le forum Programmation Linux de developpez.com



Il y a donc au moins 4 possibilités pour répondre a ton objectif de GUI

[Mac LAK]

Pourrais tu indiquer pour les langages que tu connais si chacun laisse la liberté du choix d’un IHM ou non, et d’une BD ou non.

J'utilise énormément Delphi, qui fournit en standard un framework graphique et des interfaces BD.

C'est difficilement modifiable a posteriori si tu fais n'importe quoi (genre mêler le code de traitement et le code IHM), mais la vitesse de développement que l'on atteint avec un tel outil - c'est un RAD, si tu l'ignores - compense à mon avis très largement ce "problème"... Il faut dire aussi que je n'aime pas les interfaces graphiques "exotiques" (j'aime bien que mes applis aient un look commun), et que la portabilité n'est pas ma préoccupation première pour des IHM (je ne rends portable que les "cœurs" d'application) : donc, exit QT et autres machins lents / lourds / portables, j'aime bien avoir des fenêtres Windows qui ressemblent à des fenêtres Windows et non pas à un bureau Linux ou Mac...

Pour ma part, j'aurais tendance à écrire une DLL "cœur" en C ou C++ pour la rendre la plus portable possible, une DLL BD en Delphi pour aller plus vite, et l'IHM en Delphi également. Tu peux passer sur Lazarus pour avoir un équivalent de Delphi sous Linux, car hélas Kylix (le portage officiel) a été abandonné.

Vu que ce langage répond à tes contraintes principales (portable Win/Linux, hautement maintenable et vitesse de dév très élevée), je trouve que ce ne serait pas un choix idiot, à condition de connaître le Pascal bien sûr.


Pour C et C++, tu as par contre à peu près tous les choix possibles existants. Il suffit dans ce cas de bien découper son projet, et tu peux utiliser à peu près n'importe quoi. En gros, il te faudra une DLL "cœur", qui effectuera le vrai boulot, une DLL "BD" de stockage avec une interface correctement étudiée, et l'IHM se contente de se connecter à la DLL principale. Elle n'est donc pas liée, ni de près, ni de loin, au traitement fonctionnel.
De même, la DLL BD est totalement asservie à la DLL principale, et n'effectue rien sans ordres explicites. On peut donc bien entendu la changer librement sans être ennuyé.

Java est également assez bien fourni à ce niveau, mais tu devras découper ton projet de façon aussi stricte qu'en C et C++. La portabilité est tacite, bien sûr. Par contre, n'appréciant pas outre mesure ce langage, je ne peux pas t'en dire beaucoup plus.

Côté langages de script (comme Python), je ne les utilise pas en tant que langage principal, mais comme langages de script intégrés à un programme écrit en C/C++. Je ne les utilise donc jamais avec des éléments comme les frameworks graphiques ou les interfaces BD.