En gros, vous avez placé la priorité sur l'interface dependant de logiciels propriétaire et torché la version 100 % libre à l'arrache, au feeling.
Pas du tout.
Nous avons fait un soft qui s'intègre dans l'environnement qui était à notre disposition pour développer/utiliser notre application.
Qt utilise des bibliothèques de Windows de la même manière lorsqu'elle tourne sous Windows. En tant que fervant défenseur des logiciels libre j'avais comme objectif de montrer l'intérêt de l'approche, et j'ai pensé depuis le début à concevoir l'application de manière à coder l'interface en GTK, ce qui s'est révélé être une formalité, validant les choix de conception.
C'est pas du tout du "feeling" et fait à l'arrache comme tu dis. C'est encore la meilleure méthode que j'ai trouvé pour proposer une intégration suffisante dans des environnements très différents comme Windows et Gnome.
Et puis le fait est que pour notre application cheznouscamarche (TM).
Donc en gros, on a une interface qui dépend de Mono torchée en une soirée à coté d'une interface bien préparée qui fonctionne sur WinForms/.Net ?
Il n'y a aucune dépendance envers Mono, la seule dépendance est envers WinForms ou GTK#, ce dernier tourne sous Windows sans Mono si ca t'amuse. Voir aucune dépendance, il est facile d'utiliser la partie métier sans aucune interface graphique.
Je me répête, franchement, un amateur de libre aura toutes les raisons de favoriser Qt.
Un amateur de libre a la première liberté d'utiliser la technologie qu'il souhaite, et je le repèterai jamais autant, ajouter une dépendance envers une bibliothèque graphique est un mauvais choix de conception. Qt n'est que partiellement intégré à Windows et ne présente donc pas une solution idéal pour ses utilisateurs. Il est donc vital de pouvoir facilement utiliser un autre toolkit si les besoins des utilisateurs s'en fait sentir.
Pour moi enfermer une application en utilisant Qt à tous les niveaux (des threads à l'IHM), c'est "fermer" un logiciel à un certain nombre d'utilisateur et de développeurs.
[^] # Re: sinon
Posté par TImaniac (site web personnel) . En réponse au journal Manque d'arguments pour Qt... Help !. Évalué à 8.
Pas du tout.
Nous avons fait un soft qui s'intègre dans l'environnement qui était à notre disposition pour développer/utiliser notre application.
Qt utilise des bibliothèques de Windows de la même manière lorsqu'elle tourne sous Windows. En tant que fervant défenseur des logiciels libre j'avais comme objectif de montrer l'intérêt de l'approche, et j'ai pensé depuis le début à concevoir l'application de manière à coder l'interface en GTK, ce qui s'est révélé être une formalité, validant les choix de conception.
C'est pas du tout du "feeling" et fait à l'arrache comme tu dis. C'est encore la meilleure méthode que j'ai trouvé pour proposer une intégration suffisante dans des environnements très différents comme Windows et Gnome.
Or Mono, c'est loin d'être considéré comme très fiable, pour le moment, si je ne m'abuse.
C'est tellement pas fiable que c'est supporté commercialement :
http://www.mono-project.com/Kickstart(...)
Et ca commence à être utilisé par un certain nombre d'entreprises :
http://www.mono-project.com/Software#Commercial_Applications(...)
Et puis le fait est que pour notre application cheznouscamarche (TM).
Donc en gros, on a une interface qui dépend de Mono torchée en une soirée à coté d'une interface bien préparée qui fonctionne sur WinForms/.Net ?
Il n'y a aucune dépendance envers Mono, la seule dépendance est envers WinForms ou GTK#, ce dernier tourne sous Windows sans Mono si ca t'amuse. Voir aucune dépendance, il est facile d'utiliser la partie métier sans aucune interface graphique.
Je me répête, franchement, un amateur de libre aura toutes les raisons de favoriser Qt.
Un amateur de libre a la première liberté d'utiliser la technologie qu'il souhaite, et je le repèterai jamais autant, ajouter une dépendance envers une bibliothèque graphique est un mauvais choix de conception. Qt n'est que partiellement intégré à Windows et ne présente donc pas une solution idéal pour ses utilisateurs. Il est donc vital de pouvoir facilement utiliser un autre toolkit si les besoins des utilisateurs s'en fait sentir.
Pour moi enfermer une application en utilisant Qt à tous les niveaux (des threads à l'IHM), c'est "fermer" un logiciel à un certain nombre d'utilisateur et de développeurs.