Forum Programmation.c# mono et QT

Posté par  (site web personnel) .
Étiquettes : aucune
0
24
mar.
2005
Bonjour,

Je souhaiterai développer une appli en C# car je trouve ce langage moderne et élégant. mono me fournit tout les outils pour cela, c'est parfait.

Pour ce qui est de l'interface graphique, il y a GTK# et Gnome# pour faire à peu près tout ce que l'on veut, C'est très bien, mais j'ai plutôt un faible pour KDE et je souhaiterai que mon appli utilise QT et éventuellement les fonctionnalités de KDE : librairies KMDI, DCOP, Kio,

J'ai trouvé ça :
http://qtcsharp.sourceforge.net/(...)
qui semble être ce que je souhaite, mais ça n'a plus l'air maintenu car les fichiers dans le CVS datent de 13 moins ou plus :(

Bon voilà, si je n'était pas casse-pieds, j'écrirais mon soft en c++ avec les kdelibs ou en C# avec GTK et Gnome, mais voilà, je voudrais faire du c# avec les kdelibs ou du moins qt.

QT# est-il abandonné, KDE aura-t-il des bindings C# ?
Quelqu'un a des infos à ce sujet ?

Question subsidiaire :
Quelle est la différence entre ces deux projets :
Mono : http://www.mono-project.com/Main_Page(...)
"Mono is a platform for running and developing modern applications, based on the ECMA/ISO Standards. Mono can run existing programs targeting the .NET or Java frameworks."
DotGnu : http://www.dotgnu.org/(...)
"DotGNU Portable.NET, an implementation of the Common Language Infrastructure (CLI), more commonly known as ".NET", includes everything that you need to compile and run C# and C applications"

Merci d'avance !
  • # .

    Posté par  (site web personnel) . Évalué à 4.

    Oui, Qt# n'est plus maintenu. Après tu peux quand même l'utiliser, ca marche plutôt pas mal, mais t'attend pas à voir un bug réparé si t'en trouve un :-)
    Pour les bindings des autres libs KDE, y'en a pas à ma connaissance.
    Cela dit en C# tu peux appeler facilement des libs natives. (c'est d'ailleur ce que fontt GTK# & Co), donc tant que personne ne se lance dedans y'en aura pas.

    Sinon Portable.NET et Mono ont les mêmes objectifs, cad fournir une plateforme libre de développement compatible avec celle de MS. Donc ce sont 2 projets "concurrents" et qui avancent chacun dans leur coin.

    De ce que je vois, Portable.NET semble moins "ambitieux" et attire moins l'attention sur lui. Mono reste plus abouti à mon avis.
    • [^] # Re: .

      Posté par  . Évalué à 5.

      Cela dit en C# tu peux appeler facilement des libs natives.

      Normalement oui mais Qt n'est pas tout à fait du C++. Le code doit d'abord passer par un préprocesseur (moc) pour donner du vrai C++. L'interfacage n'est donc pas forcément trivial. D'ailleurs les bindings Qt/KDE utilisent souvent QtC, une api en C qui encapsule tout ce bordel.

      Les bindings récents pour Qt/KDE utilisent Smoke/Korundum (voir http://developer.kde.org/language-bindings/)(...) qui est généré à partir des en têtes des libs Qt/KDE. Ca permet d'éviter d'avoir à se taper l'implémentation des bindings à la main et la migration à chaque changement d'API.

      Sinon Portable.NET et Mono ont les mêmes objectifs, cad fournir une plateforme libre de développement compatible avec celle de MS.

      Il y a quand même quelques divergences d'opinions:

      - Mono vise une compatibilité maximale avec les outils MS. Il implémente donc beaucoup de choses qui ne font pas partie des standards ECMA (ASP.NET, VB.NET, etc) et qui peuvent potentiellement poser de problèmes légaux. DotGnu ne se base que sur ce qui a été standardisé.

      - Toujours d'un point de vue légal, les developpeurs de Mono n'hésitent pas à poser directement des questions à MS sur les points dont ils ont besoins pour leur implémentation. DotGnu applique une politique très stricte, semblable à celle de Samba : On ne touche à aucun document, aucune information, en provenance de MS avant d'avoir vérifié soigneusement les conditions d'utilisation.

      - Mono mise beaucoup sur GTK# comme toolkit graphique et sur l'interface avec Gnome. DotGnu mise System.Windows.Forms le namespace utilisé aussi par MS.

      - Mono est sous license BSD, DotGnu sous GPL/LGPL

      - Mono est fortement soutenu par Novell. DotGnu ne semble pas avoir de grosse boite derrière lui.
      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 2.

        Merci beaucoup à tous les deux pour vos éclaircissements.

        Je vais me faire une raison et utiliser GTK# :)
      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 3.

        L'interfacage n'est donc pas forcément trivial.
        Bah si suffit d'appeler Smoke/Korundum depuis C# :)

        DotGnu ne se base que sur ce qui a été standardisé.
        Pourquoi ils implémentent les WinForms alors ?

        On ne touche à aucun document, aucune information, en provenance de MS avant d'avoir vérifié soigneusement les conditions d'utilisation.
        Ils ont la même politique chez Mono, avec en plus Novell pour contrôler la légalité de l'implémentation vis-à-vis des brevets déposés (mais toujours pas validés).
        Les dev de Mono discutent avec ceux de MS en tant que co-développeurs des normes de l'ECMA.

        Mono est sous license BSD, DotGnu sous GPL/LGPL
        Mono est sous GPL, LGPL, MIT.
        • [^] # Re: .

          Posté par  . Évalué à 2.

          Bah si suffit d'appeler Smoke/Korundum depuis C# :)
          Ces composants font partie de kdebindings. Du coup il "suffit" de porter les libs kde sous windows. Simple, non ?

          Pourquoi ils implémentent les WinForms alors ?
          Tiens, c'est vrai, les WinForms n'en font pas partie. Un début d'explication ici:
          http://wiki2.dotgnu.info/ClassLibsOverview(...)
          J'aime bien ça aussi :
          http://www.mono-project.com/FAQ:_Licensing#Is_Mono_only_an_implemen(...)
          Avec la partie ECMA (en cyan) il doit y avoir moyen de faire un Hello World, au moins. :o)

          avec en plus Novell pour contrôler la légalité de l'implémentation vis-à-vis des brevets déposés
          Mais Novell a aussi fait savoir que si un jour il fallait payer une license pour cause de brevet il soutiendraient leur clients et paieraient la license. C'est aussi une des raisons qui leur ont fait choisir la license MIT (j'avais confondu avec BSD) pour les librairies. Avec la GPL/LGPL, s'il y a un problème de brevet, le logiciel n'est plus distribuable en l'état, il faut retirer le code qui pose problème. Avec BSD/MIT/X11, on peut payer pour régulariser sa situation mais ce n'est plus libre.
          • [^] # Re: .

            Posté par  (site web personnel) . Évalué à 2.

            Mmmh, merci beaucoup pour le lien concernant les dangers namespace par namespace.
            Enfin à ce que je vois ils implémentent en gros la même chose que Mono quand même.
            Je suis surpris de voir qu'au finale dans la partie non normalisé il n'y a pas grand chose qui semble poser de problèmes juridique, en gros y'a la partie Reflection.Emit qui est en train d'être remplacé dans Mono par une lib beaucoup plus puissante, les *Services, pas implémentés dans Mono, CompilerServices/CodeDom/ComponentModel sont spécifiques à chaque implémentation du compilo C#, donc différente dans Mono que chez MS... et même pas de problème sur les WinForms ! C'est fort ca :)
            En tout cas je comprends mieux l'affirmation de MDI qui dit qu'avec Novell ils n'ont strictement rien trouvé d'enmerdant concernant d'éventuels brevets qui n'ont toujors pas été validés.
    • [^] # kde + C# : peut-être pas perdu..

      Posté par  . Évalué à 1.

      je vois que tu es très actif sur dlfp pour tout ce qui touche à .net/mono.
      Sais-tu clairement si on peut donc utiliser C# avec Qt/Kde grâce à Smoke? Je ne trouve aucune info là-dessus.
      D'autre part, le site Qtcsharp est à l'abandon, mais le feature plan de KDE (http://developer.kde.org/development-versions/kde-3.5-features.html(...) prévoit l'intégration des bindins C #/KDE. Bindings réalisés par Adam Treat, développeur de Qtcsharp. Pour moi c'est une excellente nouvelle... Le cvs de qtcsharp laissait également penser que tout n'était pas "mort" , il bougeait toujours quand j'ai été voir pour la dernière fois(fin 2004?).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.