Je crois qu'on peut compter sur l'industrie des biens de consommations basés sur l'écriture pour aller faire des pieds et des mains au sénat, où l'amendement peut encore être lui-même amendé.
Si je comprends bien, ce que tu veux au final, c'est faire une bibliothèque (voire bibliothèque slash framework) pour C# qui intègrerait des concepts C# et Qt (donc plus loin qu'un binding). Si je reformule, ce serait une couche intermédiaire entre C# et Qt, et tu imagines que ça serait intéressant de virer toutes les autres API de C# de manière à ce qu'il ne reste plus que ta couche vers Qt. Là par contre, je ne comprends carrément plus.
Je trouve que l'idée de base est bonne (une bibliothèque C# pour Qt), mais je ne comprends pas le besoin de virer le reste. Il y a plein de choses couvertes par l'API C# qui ne le sont pas par Qt, ça me semble dommage de faire un RAZ de l'API (d'ailleurs tu ne justifies pas pourquoi tu veux te débarrasser de l'API actuelle de C#).
En tout cas, ça me semblerait plus facile à intégrer dans un environnement de développement en tant que bibliothèque additionnelle que comme "langage" (ça n'en serait pas un vraiment puisque ça reste du C#), incompatible avec le reste du monde (en l'occurrence, incompatible avec C++ ET avec le C# standard).
# Reste encore à passer le sénat.
Posté par davenouille . En réponse au journal TVA réduite uniquement sur les livres numériques vendus dans des formats ouverts ?. Évalué à 9.
Je crois qu'on peut compter sur l'industrie des biens de consommations basés sur l'écriture pour aller faire des pieds et des mains au sénat, où l'amendement peut encore être lui-même amendé.
# pourquoi virer l'API standard de C# ?
Posté par davenouille . En réponse au journal Mélanger les syntaxes de C# et de Qt. Évalué à 3.
Si je comprends bien, ce que tu veux au final, c'est faire une bibliothèque (voire bibliothèque slash framework) pour C# qui intègrerait des concepts C# et Qt (donc plus loin qu'un binding). Si je reformule, ce serait une couche intermédiaire entre C# et Qt, et tu imagines que ça serait intéressant de virer toutes les autres API de C# de manière à ce qu'il ne reste plus que ta couche vers Qt. Là par contre, je ne comprends carrément plus.
Je trouve que l'idée de base est bonne (une bibliothèque C# pour Qt), mais je ne comprends pas le besoin de virer le reste. Il y a plein de choses couvertes par l'API C# qui ne le sont pas par Qt, ça me semble dommage de faire un RAZ de l'API (d'ailleurs tu ne justifies pas pourquoi tu veux te débarrasser de l'API actuelle de C#).
En tout cas, ça me semblerait plus facile à intégrer dans un environnement de développement en tant que bibliothèque additionnelle que comme "langage" (ça n'en serait pas un vraiment puisque ça reste du C#), incompatible avec le reste du monde (en l'occurrence, incompatible avec C++ ET avec le C# standard).