... [...] je n'en ai aucune idée, je ne fais pas d'interface graphique
Honnnêtement TTK, c'est vraiment pas terrible, c'est basé sur Tk ce qui n'est pas ce qui se fait de plus facile à utiliser de nos jours dès qu'on veut faire un truc un peu plus complexe que trois boutons et un champ texte (genre une fenêtre principale d'application avec des panneaux...). C'est très bien pour faire un truc rapidement en Python, mais c'est tout.
L'intégration TTK avec Gtk+/Qt est plus ou moins expérimentale (ça fonctionne pas out-of-the box sous Debian ou Ubuntu...)
Je passe sur le serveur web ("à la CUPS"). C'est surement jouable pour la configuration d'un serveur d'impression mais pour une application graphique, ce sera beaucoup beaucoup plus long et difficile à coder que n'importe quoi d'autre. Sans compter les performances et le déploiement.
[...] bindings type Cpython
Gni ? CPython c'est l'interpréteur "standard" et officiel de "Python". Cython est un compilateur de code Python et pseudo-Python (langage basé sur Pyrex) vers C. Du coup, je sais pas duquel tu parles.
D'autre part, cette approche—utiliser du Python autant que possible et ne faire en C que les parties dont la performance est critique—est certes très bonne en théorique mais un peu lourde en pratique. Je m'explique : si on veut faire ça, il faut commencer à profiler l'application en profondeur, découper les parties que l'on fait en C/Cython et celles que l'on fait en Python, s'occuper éventuellement de la glue entre Python et C.
Bref, c'est long (et relativement compliqué au final). C'était l'approche utilisée dans une application sur laquelle j'ai développé (oui, parce que ça devient marrant quand il faut synchroniser les threads du backend avec l'interface graphique...) et parfois, j'ai l'impression qu'on perd plus de temps avec cette approche que de tout faire en Java. D'autant plus que dans certains cas (widgets List et TreeView notamment), même mettre à jour l'interface graphique en Python peut devenir lent (l'interface va manquer de réactivité). Tout ça est loin d'être génial en pratique.
[^] # Re: Sinon
Posté par X345 . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 2.
Honnnêtement TTK, c'est vraiment pas terrible, c'est basé sur Tk ce qui n'est pas ce qui se fait de plus facile à utiliser de nos jours dès qu'on veut faire un truc un peu plus complexe que trois boutons et un champ texte (genre une fenêtre principale d'application avec des panneaux...). C'est très bien pour faire un truc rapidement en Python, mais c'est tout.
L'intégration TTK avec Gtk+/Qt est plus ou moins expérimentale (ça fonctionne pas out-of-the box sous Debian ou Ubuntu...)
Je passe sur le serveur web ("à la CUPS"). C'est surement jouable pour la configuration d'un serveur d'impression mais pour une application graphique, ce sera beaucoup beaucoup plus long et difficile à coder que n'importe quoi d'autre. Sans compter les performances et le déploiement.
Gni ? CPython c'est l'interpréteur "standard" et officiel de "Python". Cython est un compilateur de code Python et pseudo-Python (langage basé sur Pyrex) vers C. Du coup, je sais pas duquel tu parles.
D'autre part, cette approche—utiliser du Python autant que possible et ne faire en C que les parties dont la performance est critique—est certes très bonne en théorique mais un peu lourde en pratique. Je m'explique : si on veut faire ça, il faut commencer à profiler l'application en profondeur, découper les parties que l'on fait en C/Cython et celles que l'on fait en Python, s'occuper éventuellement de la glue entre Python et C.
Bref, c'est long (et relativement compliqué au final). C'était l'approche utilisée dans une application sur laquelle j'ai développé (oui, parce que ça devient marrant quand il faut synchroniser les threads du backend avec l'interface graphique...) et parfois, j'ai l'impression qu'on perd plus de temps avec cette approche que de tout faire en Java. D'autant plus que dans certains cas (widgets List et TreeView notamment), même mettre à jour l'interface graphique en Python peut devenir lent (l'interface va manquer de réactivité). Tout ça est loin d'être génial en pratique.