C'est la première version en LGPL, permettant ainsi de l'utiliser même pour un développement propriétaire.
Cette version apporte nombre d'améliorations après le gros bond en avant de la précédente version majeure, la 4.4. En même temps que la sortie de cette version, Qt Software (qui est un département de Nokia), distribue la première version stable de son environnement de développement intégré, Qt Creator. Qt est une bibliothèque C++ et Java. Mais cette dernière version ne sera plus maintenue officiellement par Qt Software et son évolution sera à la charge de la communauté.
Utilisée principalement en C++, Qt est bien plus qu'une simple bibliothèque graphique car elle regroupe (en vrac) :
- Du réseau et un moteur de rendu HTML basé sur Webkit ;
- Du XML ;
- De la base de données ;
- Du multimédia via Phonon (uniquement en lecture pour l'instant) ;
- QtScript, un langage de script (basé sur JavaScript) ;
- De l'OpenGL ;
- Qt Linguist, pour l'internationalisation ;
- La gestion des threads ;
- Un système de test unitaires ;
- Qt Designer, un créateur d'interface ;
- etc.
Pour les nouveautés de Qt 4.5 :
- Mise à jour de QtWebkit : le nouveau moteur JavaScript est présent, les greffons Netscape sont utilisables (bonjour Flash !), les nouvelles balises du HTML 5 sont utilisables et utilisent Phonon ;
- Diverses améliorations des performances et l'apparition d'une bibliothèque mesurant les performances, QtBenchLib ;
- L'utilisation de Cocoa pour la version Mac OS X ;
- L'utilisation de Phonon et QtWebkit pour Windows CE ;
- Un moteur de transformation XSLT ;
- Un débogueur pour QtScript ;
- L'écriture de fichier OpenDocument ;
- Une meilleure intégration pour les environnements utilisant GTK ;
- Diverses améliorations dans Qt Linguist, Qt Designer, les performances graphiques, etc.
En résumé, Qt c'est bon, mangez-en !
Aller plus loin
- L'annonce (2 clics)
- La description en détail des principales nouveauté (2 clics)
- Le changelog (2 clics)
- La documentation technique (6 clics)
- L'article sur Wikipédia (3 clics)
# Erreurs de français
Posté par sanao . Évalué à 3.
[^] # Re: Erreurs de français
Posté par BAud (site web personnel) . Évalué à 5.
Faut pas croire, mais tous les relecteurs ne sont pas forcément bons en orthographe :D ('fin ça peut se faire après coup, la preuve :p).
[^] # Re: Erreurs de français
Posté par sanao . Évalué à 5.
Merci.
# Re: Sortie de Qt 4.5
Posté par Gof (site web personnel) . Évalué à 10.
Il était déjà possible de l'utiliser pour faire du dévelopement propriétaitaire.
La différence c'est que avant il fallait payer une licence et que maintenant c'est gratuit.
(Il est toujours possible de payer une licence si on souhaite du support)
[^] # Re: Sortie de Qt 4.5
Posté par Benjamin Poulain (site web personnel) . Évalué à 5.
# PyQt
Posté par Tony Ducrocq . Évalué à 2.
[^] # Re: PyQt
Posté par Alexis Ménard (site web personnel) . Évalué à 2.
Maintenant que c'est gratuit, je pense que les SSII ou co vont y penser sérieusement. Il faut juste que les devs réveillent un peu les chefs de projets au moment des choix de techno pour choisir Qt.
[^] # Re: PyQt
Posté par Philippe F (site web personnel) . Évalué à 2.
[^] # Re: PyQt
Posté par Tony Ducrocq . Évalué à -1.
D'une PME peut-être, d'une start-up non ...
[^] # Re: PyQt
Posté par GeneralZod . Évalué à 2.
Avant la LGPL-isation de Qt 4.5, pour développer un logiciel privateur en PyQt, il fallait débourser le prix de la licence Qt (entre 2000€ et 3000€/développeur) et de la licence PyQt. C'était réellement un frein à la progression de PyQt en entreprise, là, ça l'est beaucoup moins.
Pour le moment, rien n'est décidé l'unique mainteneur évalue les options qui s'offrent à lui
Hein, n'oublions que RiverBank n'a pas la solidité financière de Nokia et qu'il faut bien payer les factures à la fin du mois. Ce serait un poil ingrat d'exiger de Phil Thompson de relicencier PyQt sans certitude que son énorme travail soit rétribué à sa juste valeur.
L'idéal serait que Qt Software décide de sponsoriser PyQt mais on n'aura très probablement la réponse qu'à la sortie de PyQt 4.5
[^] # Re: PyQt
Posté par soulflyb (Mastodon) . Évalué à 2.
Evidemment ce serait l'idéal pour les dev Python, mais il ne faut vraiment pas compter là dessus, car entre l'abandon de Qt Jambi et celui de Qt Extended, je doute fort que Nokia ait dans l'idée de promouvoir un autre binding alors qu'ils abandonnent les projets "périphériques" à la louche...
[^] # Re: PyQt
Posté par Gniarf . Évalué à 6.
> D'une PME peut-être, d'une start-up non ...
c'est une farce ? c'est la moitié ou le tiers du prix d'une machine de dev ou d'un portable pour faire des demos chez les gentils gens qui lacheront les sous ensuite.
[^] # Re: PyQt
Posté par Zenitram (site web personnel) . Évalué à 3.
Bon, certes, c'est pour chipoter, car si on est à 300€ près, c'est mal parti même pour une startup! (vu toutes les charges qu'il y a ensuite :) )
[^] # Re: PyQt
Posté par Bozo_le_clown . Évalué à 4.
[^] # Re: PyQt
Posté par GeneralZod . Évalué à 2.
Là, où ça se corse, c'est si tu incorpore ton code BSD dans un ensemble sous une licence privatrice ou incompatible avec la GPL (ce que te permet la licence BSD), là, tu es obligé d'acheter une licence commerciale de PyQt.
Tu n'as pas le droit de faire tourner une application GPL avec la version privatrice de PyQt à moins de rajouter une clause d'exception de liens avec des bibliothèques non-libres.
Donc en résumé:
* les sources peuvent rester sous licence BSD.
* si je lie mon application avec la version GPL de PyQt, l'ensemble passe sous GPL.
* si je lie mon application avec la version privatrice, je fais comme je veux sauf à utiliser la licence GPL nue.
[^] # Re: PyQt
Posté par Gof (site web personnel) . Évalué à 1.
Mais en quoi la licence payante de PyQt est elle privatrice ?
Laquelle des 4 libertés prétendues fondamentales n'est pas réspectée ?
[^] # Re: PyQt
Posté par GeneralZod . Évalué à 2.
Toutes potentiellement. La licence commerciale de PyQt est modelé sur celle de Qt [1]
* Liberté d'exécuter le programme.
==> Cf plus bas, royalties
* Liberté d'étudier le fonctionnement du programme
==> certains bouts de la version commerciale de Qt/PyQt ne sont pas libres notamment ActiveQt. Si tu veux vérifier, lance la démo webbrower.py dans le répertoire ActiveQt et lis le message qui s'affiche.
* Liberté de redistribuer des copies
==> Ce n'est pas systèmatique mais dans certains cas, Qt Software peut demander des royalties pour l'installation de runtime. C'est surtout destiné à l'embarqué mais ça peut également s'appliquer à la version standard de Qt dans certains cas.
* Liberté d'améliorer le programme et de publier ces améliorations.
==> la licence commerciale de Qt t'interdit de publier le source de ton application.
No source code must be disclosed
[1] http://www.qtsoftware.com/products/licensing/licensing#qt-co(...)
[^] # Re: PyQt
Posté par fearan . Évalué à 3.
je crois que tu as mal interprété, c'est pas can ou may mais must. C'est à dire que ce n'est pas obligatoire. (par opposition à la GPL)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: PyQt
Posté par GeneralZod . Évalué à 2.
# QGtkStyle ?
Posté par O'neam Anne . Évalué à 7.
Il s'agit bien de QGtkStyle, à priori, attendu par certains Gnomistes/Xfceistes comme le Messie (ou presque) :·D ?
http://labs.trolltech.com/page/Projects/Styles/GtkStyle
En espérant que QGtkStyle soit utilisé rapidement dans ma distribution, pour mon plus grand bonheur :·D.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: QGtkStyle ?
Posté par sanao . Évalué à 3.
Par contre je ne sais pas si tous les widgets Qt ont un équivalent GTK. Car si ce n'est pas le cas, j'image que c'est le moteur de Qt qui reprend la main.
Quelqu'un connait les détails?
[^] # Re: QGtkStyle ?
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Tu n'utilises que le moteur bas-niveau de GTK pour dessiner tes widget Qt mais tu ne fais pas correspondre un bouton Qt par un bouton GTK, une checkbox Qt par une checkbox GTK, etc
[^] # Re: QGtkStyle ?
Posté par Gof (site web personnel) . Évalué à 6.
En interne le style va demander à Gtk+ de dessiner les widgets ou primitives dans des buffers (mis en cache) de manière à dessiner tout exactement comme le fait Gtk+.
Normalement la différence entre une vrai application Gtk et une application Qt ne devrais quasiment pas se voir.
(Les applications KDE risquent d'être légèrement moins intégrées qu'une application "pure Qt" car elles ont des widgets qui ne sont pas pris en charge par le style Qt.
Cette différence devrais toutefois être assez limitée.)
[^] # Re: QGtkStyle ?
Posté par Benjamin Poulain (site web personnel) . Évalué à 3.
Qui sait, ça poussera peut être GTK à mieux s'intégrer à KDE?
# OpenDocument...
Posté par windu.2b . Évalué à 3.
[^] # Re: OpenDocument...
Posté par sanao . Évalué à 2.
# Précisions ?
Posté par Vincent-Xavier JUMEL (site web personnel) . Évalué à 2.
Quelqu'un a des précisions sur cette assertion ?
[^] # Re: Précisions ?
Posté par Gof (site web personnel) . Évalué à 3.
En fait ce n'est que Jambi (les bindings Java de Qt) qui ne seront plus maintenu officiellement par Nokia
https://linuxfr.org/~SOULfly_B/27899.html
Qt (La bibliotèque C++) restera dévelopée, maintenue et suportée par Nokia biensur.
(Jambi n'est que très peu utilisé comparé à Qt)
[^] # Re: Précisions ?
Posté par sanao . Évalué à 3.
La version 4.5 est en LGPL et le support par Qt Software s'arrête en mars 2010.
# Qyoto/Kimono
Posté par vida18 . Évalué à -2.
https://www.ohloh.net/p/qyoto
http://ekarchive.elikirk.com/david/qyoto/
[^] # Re: Qyoto/Kimono
Posté par Benjamin Poulain (site web personnel) . Évalué à 4.
Faire du .Net cross plateforme est un combat perdu (pour ce que j'ai pu essayer de Mono/Moonlight). Alors que de l'autre coté faire du cross plateforme avec Qt est vraiment simple.
[^] # Re: Qyoto/Kimono
Posté par Kangs . Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par GeneralZod . Évalué à 3.
http://doc.trolltech.com/4.5/activeqt-dotnet.html
En gros, si tu veux utiliser Qt en .Net, soit tu utilises les outils associés à C++/CLI (pas standard, pas supporté par Mono), soit tu utilises ActiveQt (en gros, tu passes par COM) qui sapusaipalibre.
[^] # Re: Qyoto/Kimono
Posté par Kangs . Évalué à 1.
Je croyais que les papiers .net/Qt n'avaient commencer qu'avec la version 4, je dois vieillir .
Mea Culpa
[^] # Re: Qyoto/Kimono
Posté par scls19fr (site web personnel) . Évalué à 0.
http://doc.trolltech.com/latest/activeqt-dotnet.html
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 1.
- si la bibliothèque est bien conçu et exporte des API "plats" portables, les bindings se font de manière portable, directement en C#. Cas de la plupart des bibliothèques C.
- si la bibliothèque exporte ses API en C++, point de salut : il faut se coltiner de la glue en C++, soit pour exporter un API plat facilement utilisable avec la solution précédente (c'est ce que fait Qyoto), soit directement en utilisant une variante de C++ capable d'intéragir avec les 2 environnements (pas portable comme langage).
- si la bibliothèque exporte ses API à travers une interface COM, directement en C# en créant un binding automatiquement. Pas portable non plus.
En gros l'équipe Qt propose sur ton lien... les 2 solutions non portables.
[^] # Re: Qyoto/Kimono
Posté par Kangs . Évalué à 4.
>En gros l'équipe Qt propose sur ton lien... les 2 solutions non portables.
De mon point vu Qt est portable, Nokia propose un framework qui est compilable avec des outils standards et portables.
.net, de mon point de vue, est une solution propriétaire née suite à un désaccord entre deux grands acteurs de l'informatique contemporaine.
Qt est portable, je ne crois pas que ce soit discutable (?)
.net c'est propriétaire et non portable, mono est censé être un substitue donc les solutions que propose Nokia, même si elles ne te plaises pas, devraient pouvoir s'appliquer pour mono.
Personnellement toutes les discutions autour de mono ne m'ont jamais convaincu de l'intérêt de ce dernier et je ne vois pas plus d'intérêt pour Qyoto.
A l'annonce de la sortie d'une version de Qt je suis surpris qu'on pose la question sur sa compatibilité avec .net, si .net est mieux pour des raisons X ou Y pourquoi vouloir utiliser Qt, mono existe son choix et probablement plus judicieux si on veut être compatible avec .net.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à -1.
Ce dont je te parle, c'est du modèle technique pour appeler des libs natives depuis la machine virtuelle implémentée dans .NET. C'est spécifié, standardisé et normalisé ISO.
Qt est portable, je ne crois pas que ce soit discutable (?)
la critique sous-jacente, c'est les API C++. Binairement, des API C++ ne sont pas portable d'un compilateur à l'autre, alors ne parlons même pas d'une plateforme à l'autre. C'est ce qui fait qu'on est obligé dans tous les bindings de se taper une couche de glue pour contourner le problème.
Qt propose les solutions de glue les plus crades : celles qui ne sont pas portable, ce qui est quand même balo pour un framework portable.
mono est censé être un substitue donc les solutions que propose Nokia, même si elles ne te plaises pas, devraient pouvoir s'appliquer pour mono.
Si les solutions que propose Nokia ne s'appliquent pas à Mono, c'est que Mono se contente d'implémenter .NET, et pas les briques non portables qu'ils proposent d'utiliser : COM ou C++/CLI.
Et c'est le même problème pour tous les langages, pas seulement Mono, en Python on peut attaquer un composant COM, donc celui de Qt, et c'est exactement le même problème : ca ne tournera que sous Windows. C'est pas pour rien que PyQt existe de la même manière qu'il y a Qyoto.
[^] # Re: Qyoto/Kimono
Posté par Kangs . Évalué à 1.
Tu connais les ABI, elles sont là pour résoudre un problème qui n'est pas spécifique au C++
>C'est ce qui fait qu'on est obligé dans tous les bindings de se taper une couche de glue pour contourner le problème.
Pourquoi penses tu que tes jugements de valeurs à 2 balles fassent fois ?
>Qt propose les solutions de glue les plus crades : celles qui ne sont pas portable, ce qui est quand même balo pour un framework portable.
Le framework est portable sur beaucoup d'OS dont MSWindows. Effectivement qu'il y ait un portage sur un logiciel fermée comme .net est surprenant. C'est .net qui devrait être ouvert est capable d'incorporer l'existant sans avoir à ajouter des extensions dans un langage ou limiter son utilisation à quelques fonctionnalités, ce qui est le comble pour un vm qui se ventait d'être utilisable par tous les langages, au final elle ne l'est par aucun en tout cas dans leurs spécifications normalisées.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 3.
Tu lis ce que je mets ou quoi ?
.NET permet le même niveau de réutilisation de l'existant que tous les autres langages comme Java ou Python. Ces derniers ont exactement les mêmes problème que .NET pour faire des bindings sur des API C++ et sont obligés de passer par une couche de glue.
Ce qui n'est pas portable, c'est les surcouches intermédiaire écrites en C/C++ que propose d'utiliser Nokia : COM ou C++/CLI. Pas le binding en soit.
Donc voilà, y'a moyen, comme en PyQt ou Jambi de faire des bindings portables pour Qt, c'est Qyoto, et Nokia ne veut pas s'y intéresser. (ce que je ne critique pas, c'est leur choix).
[^] # Re: Qyoto/Kimono
Posté par sanao . Évalué à 7.
Qt assure la portabilité au niveau des sources si ton application est 100% Qt et n'utilise pas les rares cas où il y a du "plateform specific" (comme dirait la documentation). Win32, .Net, X11 et autres joyeusetés MacOSiennes disponibles à travers Qt ne sont pas portables et doivent se régler à coup de #ifdef
Qt Software est très clair sur ce point. Alors les critiquer sur ce point est un peu fort du café.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
http://doc.trolltech.com/4.5/activeqt-dotnet.html
Moi aussi je trouve ca fort de café que les équipes de Nokia conseille d'utiliser des glues non portables pour utiliser un framework portable, mais j'invente rien, c'est eux qui l'écrivent hein.
[^] # Re: Qyoto/Kimono
Posté par sanao . Évalué à 4.
Le contrat est que Qt est portable au niveau des sources. C'est le cas dans quasiment toute son API. Les 2 à 3% restant sont spécifiques à une plateforme (Windows, UNIX, MacOS, Windows CE, S60, etc...). Si quelqu'un veut utiliser du spécifique, Qt Software a pensé à lui mais prévient à chaque fois que ce n'est pas portable.
Si tu veux du portable, utilise uniquement Qt.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par Gof (site web personnel) . Évalué à 3.
Ça c'est toi qui le dit.
Mais le but de ActiveQt n'est pas du tout de créé des bindings pour faciliter le dévelopement en .Net. C'est de pouvoir utiliser C++ et Qt tout en s'intégrant dans des applications que d'autres auraient écrit en .Net
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à -3.
C'est pas une idée, une pensée, c'est un fait. Le socle technique de .NET/C# est portable.
[^] # Re: Qyoto/Kimono
Posté par Benjamin Poulain (site web personnel) . Évalué à 4.
Avec Mono tu passes ton temps à contourner les différences entre les deux implémentation, ou tu finis par utiliser Mono sur Windows pour avoir quelque chose qui "fonctionne" partout. :(
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 1.
En quoi le socle technique/C# n'est pas portable ?
En quoi MS ne respecte pas du tout la norme ISO correspondante ?
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 4.
C'est rigolo a quel point c'est multiplateforme les logiciels C#/.Net et tout particulierement silverlight... Non non aucun abus de position dominante la dedans naturellement...
Companies using software other than Microsoft's are unable to bid at many Portuguese public tenders. This is due to the use of Silverlight 2.0 technology
Le problème vient naturellement du retard de mono et moonlight car comme par hasard les technos "portables" de Microsoft ce ne sont jamais eux qui les portes (contrairement à Sun et Adobe pour ce qui est de java et flash) et les projets qui implémentent cela sont "curieusement" en retard. Cela me rappelle les versions doc, dès qu'une version marchottait chez la concurrence une nouvelle déclinaison (incompatible naturellement) faisait son apparition.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
MS a porté Silverlight sur Mac.
Quand ils veulent, ils peuvent.
Mais bon on est d'accord que Mono a du retard sur l'implémentation des bibliothèques disponibles dans .NET. Mais c'est pas un problème de technique, c'est essentiellement un problème de moyen.
Ca m'intéresse pas de discuter de ça, là on parle pas des bibliothèques de .NET mais de la bibliothèque Qt et de son utilisation dans Mono.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 2.
Pour la version 2.0 uniquement pour la plateforme Intel (amusant comme la portabilité est tout de suite limité...)
Quand ils veulent, ils peuvent.
CQFD Microsoft ne veut pas porter la moindre de ses logiciels ou technologies sous Linux d'où le fait que, de mon point de vue d'utilisateur exclusif de Linux, Microsoft soit un parasite négatif. D'ailleurs j'attend toujours la réponse à ma question sur l'apport direct de Microsoft à Linux de la part des défenseurs de cette entreprise. Il m'attaque en tentant de dénigrer mes propos en les faisant passer pour haineux (je suis probablement un dictacteur en puissance de leur point de vue...) mais n'apporte aucun véritable argument au sujet.
Ca m'intéresse pas de discuter de ça, là on parle pas des bibliothèques de .NET mais de la bibliothèque Qt et de son utilisation dans Mono.
C'est bien toi qui est venu au secours de .Net et dire que Qt faisait un travail de merde, n'est ce pas? C'est un peu facile de critiquer un et de refuser de parler des "petits"problèmes l'autre.
Qt est multiplateformes, C#/.Net ne l'est pas point barre que ce soit à cause d'une volonté politique et que mono est à la traine personnellement je m'en tape ceci est un fait et montre à quel point il est dangereux d'utiliser des technologies liés à Microsoft.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 1.
Je ne cherches pas à défendre MS, je n'aime pas leur politique mono-plateforme, je n'aime pas leur politique de brevet, c'est pas pour autant que toutes les technos qu'ils concoivent sont pourris et que rien ne mérite de l'attention.
http://en.wikipedia.org/wiki/Common_Language_Infrastructure
"The specification defines an environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures."
C'est un environnement conçu dès le départ pour être portable, c'est un fait, que ca te plaise ou non. Que MS ne veuille pas porter son implémentation, c'est son problème, et ce troll ne m'intéresse pas, je parle de logiciel libre, de linux, de mono, de standards, de technique.
Toi tu nous ressors ton vomi traditionnel anti-MS là où c'est pas le sujet, qui est je te le rappel les bindings C# pour Qt. C# est un standard, qui s'appui sur une infrastructure ouverte, standard et parfaitement implémentée sous Linux, on peut se cantonner à ce périmètre sans que tu vomisse sur une implémentation proprio pour un OS proprio non ?
Qt est multiplateformes
Qt propose des briques qui ne sont pas portable et même pas libre, c'est une infime partie qui ne remet pas en cause l'intérêt de Qt, mais qui mérite critique quand on propose cette solution sur LinuxFR il me semble.
montre à quel point il est dangereux d'utiliser des technologies liés à Microsoft.
A part montrer que tu sais même pas FUDer correctement, tu montres pas grand chose.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 0.
Et voila encore une tentative de discréditer mes dires uniquement en me liant à d'autres participant de ce site. Ne pourrais tu pas te contenter de mes dires à moi et d'argumenter correctement contre?
C'est un environnement conçu dès le départ pour être portable, c'est un fait, que ca te plaise ou non.
Ais je nier cela ou ais-je dit que dans les fait C#/.Net n'est pas portable. Il l'est potentiellement mais il ne l'est pas dans les faits. Le nier c'est propager un mensonge. Toute la différence réside dans le conditionnel et le présent. .Net a presque 10 ans et Microsoft, comme TU le dis si bien, refuse de sortir des versions autres que sur sa plateforme et une partie sur Mac.
Toi tu nous ressors ton vomi traditionnel anti-MS là où c'est pas le sujet
Et voila encore une tentative de discrédit sans aucun argument. Je vais te reposer une question simple à laquelle tu refuses de répondre:
Quel est l'apport direct positif de Microsoft à Linux?
Le jour où toi ou quelqu'un d'autre arrivera à répondre à cette question on pourra discuter d'ici là je ne subirai que des insultes de ta part (et d'autre) parceque je soulève un point génant pour vous.
Qt propose des briques qui ne sont pas portable et même pas libre
Tiens c'est rigolo mais Qt étant GPL/LGPL je ne vois pas comment cela ne peut pas être libre mais tu veux peut être parler d'un ajout à Qt non officiel?
A part montrer que tu sais même pas FUDer correctement, tu montres pas grand chose.
Je n'ai pas mis d'argument? Et le lien au dessus qui montre que pour que appliquer à des contrats publics au Portugal tu es forcé de te servir de technologies microsoft non disponible pour la majorité des systèmes concurrents? Il y a même plainte auprès de la commission européenne alors dire que les arguments sont creux c'est un peu facile tout de même.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
Eh c'est toi qui a pondu tout un paragraphe sur ta personne.
is je nier cela ou ais-je dit que dans les fait C#/.Net n'est pas portable.
J'ai depuis le départ pris soin de parler du "socle technique" pour faire référence à la technique pure et simple, la CLI quoi. Ca c'est portable. Et c'est ca qui nous intéresse vu qu'on parle technique. Que .NET soit pas porté pour d'obscure raisons marketing, on s'en branle, c'est pas le sujet. Je vois bien que t'as qu'une envie s'est de le crier haut et fort, mais ca n'intéresse pas grand monde je penses dans ce débat.
Quel est l'apport direct positif de Microsoft à Linux?
C'est pas le sujet, et j'en ai rien à péter de toute façon de savoir ce que MS apporte ou non à Linux.
Le jour où toi ou quelqu'un d'autre arrivera à répondre à cette question on pourra discuter d'ici là je ne subirai que des insultes de ta part (et d'autre) parceque je soulève un point génant pour vous.
Mais ca me gène pas, c'est juste que c'est totalement HS. Trouve quelqu'un d'autre pour troller sur le sujet, ca m'intéresse pas de savoir si MS apporte quelque chose à Linux.
Tiens c'est rigolo mais Qt étant GPL/LGPL je ne vois pas comment cela ne peut pas être libre mais tu veux peut être parler d'un ajout à Qt non officiel?
Je suis pas un spécialiste, mais c'est marqué "The ActiveQt modules are part of the Qt Full Framework Edition. They are not part of the Open Source Versions of Qt."
Ca me paraît donc officiel et pas Open source. Après je suis peut être très mauvais en anglais.
Je n'ai pas mis d'argument?
C'est pas une question d'argument, tu dis juste "c'est dangereux" comme ca pif paf comme un cheveu sur la soupe à la fin d'un paragraphe sans queue ni tête.
Et le lien au dessus qui montre que pour que appliquer à des contrats publics au Portugal tu es forcé de te servir de technologies microsoft non disponible pour la majorité des systèmes concurrents?
Je vois pas le rapport avec la dangerosité de Mono. Juste une critique de la politique commerciale de MS, mais là encore c'est pas le sujet.
Il y a même plainte auprès de la commission européenne alors dire que les arguments sont creux c'est un peu facile tout de même.
C'est un peu ton problème : tu trouves des arguments qui totalement hors contexte ou hors sujet. Tu affirmes des trucs, parfois vrais et argumentés, mais sans rapport direct avec ce à quoi tu réponds.
Maintenant j'arrête avec ton troll à 2 balles, je préfères mon troll technique initial.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
En gros tu critiques que Qt a utilisé une solution technique non portable pour un truc qui est n'existe que sur une seule et une seule plateforme. T'es tu posé la question sous l'angle:
"A quoi cela sert de faire un truc portable pour un truc qui ne l'est que théoriquement?"
Et si cela se trouve c'est sale mais plus rapide de faire comme ça. Le but de Qt étant d'être multiplateforme ne pas faire d'effort pour un truc monoplateforme et on ne peut plus logique et cela n'a, en effet rien avoir avec la technique quoique si cela se trouve c'est beaucoup plus complexe de faire le truc que tu suggères, mais comme pour C#/.Net de Microsoft un choix politique. On peut aussi rajouter que l'équipe mono, si l'on prend la partie plus multiplateformes de la technos, est énormément plus orientés Gnome/Gtk et donc la aussi les incitations pour Qt sont faibles.
Dans ce cas la tu peux en effet t'amuser à descendre Qt pour ses choix politiques cela mais ne vient pas te plaindre si des linuxiens viennent faire la même chose sur des technologies politiquement monoplateforme...
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben Mono me semble une implémentation largement conforme de la CLI, y'a sûrement des bugs mais je n'en ai rencontré aucun. Donc en pratique c'est portable, pas que en théorie.
Et si cela se trouve c'est sale mais plus rapide de faire comme ça.
Oué bah oué, c'est le cas. ActiveQt est une interface pour Windows COM, c'est un effet de bord si c'est facilement utilisable dans .NET. Mais ca reste une techno purement MS (même s'il y a eu des tentatives de portages de COM).
quoique si cela se trouve c'est beaucoup plus complexe de faire le truc que tu suggères
C'est effectivement plus complexe, et Nokia le dit d'ailleur très clairement dans son article. Mais cette complexité, tous les bindings de Qt l'ont, c'est un problème lié au choix technique de Qt d'exporter ses API sous la forme de classes C++, qui sont par nature beaucoup plus difficile à binder qu'un API C.
si l'on prend la partie plus multiplateformes de la technos, est énormément plus orientés Gnome/Gtk et donc la aussi les incitations pour Qt sont faibles.
Ben moi j'aurai trouvé ca cool d'avoir une alternative à Gnome/Gtk justement. Visiblement tout ceux qui s'intéresse à Qyoto aussi.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 2.
Ben moi j'aurai trouvé ca cool d'avoir une alternative à Gnome/Gtk justement. Visiblement tout ceux qui s'intéresse à Qyoto aussi.
Pourquoi le projet mono ne le fait pas alors? Est-il trop lié à Gnome/Gtk? Pourquoi les efforts devraient forcement venir de Qt alors que leur librairies est déjà multiplateforme et plus complète que tout ce qui est disponible à côté dans le monde du libre?
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
Parcque Qt est chiant à binder :)
pourquoi les efforts devraient forcement venir de Qt alors que leur librairies est déjà multiplateforme
Ben c'est un effort qui intéresserait tous ceux qui font des bindings, pas plus Mono que d'autres. Je ne demande pas à Qt de maintenir des bindings pour tous les langages de la terre, mono n'est effectivement pas un langage super répendu sur Linux qui mérite plus leur attention qu'un autre langage. Je trouverais juste ca cool s'ils pensaient à ceux qui ne veulent pas faire de C++ et faciliter la vie de ceux qui créent des bindings pour Mono, Python Ruby ou je ne sais quoi. Il leur suffirait de maintenir un seul binding, en C.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
et pas Gtk? Enfin cela semble s'être améliorer mais bon pygtk il est toujours à la bourre par rapport à Gtk actuellement sa dernière version est la 2.2.12 alors que GtK en est à la version 2.14... PyQt en est à la version 4.4 et les snapshot pour la version 4.5 sont disponible. Tiens par contre grâce à ce message je me suis aperçu que la documentation de pygtk était enfin là.
Il leur suffirait de maintenir un seul binding, en C.
Ouh le vilain troll C versus C++.
[^] # Re: Qyoto/Kimono
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Gtk est en C, Qt utilise à fond les spécificités du C++.
Binder une lib C++ en C, c'est pas gagné. Ou alors tu le fais en te plaçant haut dans le binding.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben de ce que j'ai essayé de faire comme binding, c'est moins chiant.
Ca s'automatise beaucoup plus simplement.
En particulier avec Mono qui propose une façon élégante, simple et portable de faire des bindings, pour peu que les ABI de la bibliothèque bindée soit portable. Et c'est tout le problème de C++ et son name mangling.
Ouh le vilain troll C versus C++.
Enfin un qui rentre dans le bon troll :)
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
[^] # Re: Qyoto/Kimono
Posté par GeneralZod . Évalué à 2.
Parce que c'est un projet communautaire ? parce que personne n'est payé pour bosser à temps plein dessus ? C'est pas les bonnes raisons qui manquent.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
[^] # Re: Qyoto/Kimono
Posté par GeneralZod . Évalué à 5.
Mais la simplicité du langage C facilite pas mal les choses pour la génération des bindings au niveau technique. De fait, le C est la lingua franca de l'informatique.
Le C++ étant un langage nettement plus complexe, c'est un peu plus délicat, le débogage est plus difficile (essaie de déboguer un module Python développé en C ou avec Boost.Python, tu m'en diras des nouvelles). Effectivement, si tu fais ton binding à la main, mieux vaut que le langage source soit en C qu'en C++.
Mais le point que tout le monde semble oublier dans cette enfilade, c'est que des frameworks tels que Qt et Gtk+ possèdent un modèle objet bien établie, imposent des conventions de code qui permettent de générer automatiquement des bindings sans trop de gruikage.
La totalité des bindings de Qt et Gtk+ sont automatiquement générés à partir du sources que ce soit PyQt avec SIP, QtJambi avec son générateur, PyGtk avec codegen, Gtkmm avec gmmproc etc ...
Une fois, l'obstacle technique du langage source dépassé, la très grande partie du boulot c'est surtout du peaufinage, rendre les APIs plus agréables et mieux intégrés au langage cible.
Bref, cette discussion c'est de la sodomisation de mouches.
[^] # Re: Qyoto/Kimono
Posté par Benjamin Poulain (site web personnel) . Évalué à 2.
http://techbase.kde.org/Development/Languages
C'est pas comme si on avait pas les outils pour le faire.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
Voudrais tu dire que parceque C#/.Net de Microsoft n'est pas déployable out-of-the-box (on passera sur le fait que ce n'est même pas dispo d'une autre façon) pour Linux ce n'est ni stable ni mature?
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
Tu veux dire que non seulement on ne peut plus utiliser le droit de citation (soit disant égale à des attaques ad hominem) mais que en plus l'usage du pronom "je" est interdit sur ce site? Et quels sont les autres règles non écrites auxquelles je le participant dois me se soumettre?
[^] # Re: Qyoto/Kimono
Posté par Gof (site web personnel) . Évalué à 3.
Mais tu aime Mono malgré sa politique plateforme Microsoft :-)
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
Trouves tu normales que les marchés publics soient interdit au non utilisateur de Microsoft?
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 3.
Mais je vois toujours pas le rapport. On parlait technique bon sang, pas politique Microsoft.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
Je veux bien discuter, mais faut argumenter alors.
En quoi le socle technique/C# n'est pas portable ?
En quoi MS ne respecte pas du tout la norme ISO correspondante ?
Tu parles de théorie moi je parle de pratique. La différence est là. En théorie Microsoft peut apporter beaucoup à l'informatique et au logiciels libres, la pratique est toute différente.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
En quoi le socle technique/C# n'est pas portable ?
En quoi MS ne respecte pas du tout la norme ISO correspondante ?
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
En quoi le socle technique/C# est porté sur différentes plateformes?
Quel est la proportion de .Net non normalisé ISO?
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
Excuses-moi, mais j'ai la flemme de te faire un rapport de 5000 pages détaillant chaque paragraphe de la spec CLI/C# pour démontrer qu'elle est effectivement portable.
Moi j'ai pointé un article wikipedia, ca vaut ce que ca vaut, qui dit explicitement que la CLI a été conçu pour être portable.
Si c'est pas le cas, tu devrais trouver rapidement des exemples montrant que la CLI de Mono n'est pas et ne peut pas être compatible avec le standard.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
D'ailleurs le point évoquer plus bas: https://linuxfr.org/comments/1013173.html#1013173 est totalement à l'ordre du jour la norme ISO de C# est totalement obsolète certes son implémentations par Microsoft a été respecté mais bon C# a tellement changé depuis (d'après tes propres journaux annonçant les versions succéssives me semble t'il) que cela ne veut presque plus rien dire. C# 3 n'est pas une norme ISO et détrompe moi je crois que ce n'est pas plus le cas pour .Net.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais bon en l'occurrence C# 3.0 s'appuie toujours sur le même socle technique : la CLI, dont la norme ISO est toujours au goût du jour et correctement implémentées par .NET et Mono. La CLI est par nature indépendante du langage (c'est un de ses intérêts) : si tu fais un binding pour la CLI, il sera utilisable dans tous les langages.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
Comme tu l'as dit toi même c'est complexe et n'intéresse globalement que très peu de monde. Les priorités de Qt sont autres et j'en suis bien content.
[^] # Re: Qyoto/Kimono
Posté par Larry Cow . Évalué à 2.
À la seule condition que la première affirmation soit effectivement fausse. Sinon, tu risques de le chercher longtemps, ton exemple.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par Benjamin Poulain (site web personnel) . Évalué à 5.
Tu essayes de faire dériver le débat avec ta première question. C# pourrait être portable, d'ailleurs Mono est portable, mais en pratique .Net ne l'est pas. J'aurais d'ailleurs bien du mal à citer une seule killer app en .Net qui tourne sur Linux et Mac. C# pourrait hypothétiquement être portable, personne ne dit le contraire.
Quand on parle de Java, on parle de l'implémentation de Sun parce que c'est la seule qui a des performances potable et c'est là cible sur lequelle on développe. Sur Java la portabilité est pas trop mal (j'ai dit portabilité, pas intégration), car tu peux te rabattre sur l'implémentation de référence, même sous Linux.
Quand on parle de .Net, on parle de l'implémentation de Microsoft. Et là rien ne vas plus parce que l'implémentation de référence n'existe que sous Windows, et que la version multiplateforme est bancale (que ce soit en terme de vitesse ou de fonctionnalités). Essaye de faire tourner une application non triviale sur MS.Net et Mono, tu vas te marrer (et je ne dis pas ça contre Mono, ils font un boulot incroyable étant donné la différence de moyen avec Microsoft!).
Mono n'as vraiment pas aidé Linux pour le moment. Aucune application .Net n'est venu de Windows vers Linux, mais de l'autre côté ça permet à Microsoft de raconter à tout le monde que si ils font du .Net c'est cross-plateforme. Et il y a des gens qui y croient.
Pour la norme ISO, le problème est que la norme a été soumise il y a longtemps, et elle n'a jamais été mise à jour. Les problèmes de la norme n'ont jamais été corrigé, et les nouveautés n'ont jamais été intégrés.
Il est ressorti d'une discutions que j'ai eu avec un ingénieur de Microsoft France que la norme est juste là pour donner du poid à son langage sur le papier. Cette norme n'est pas du tout la référence utilisé par Microsoft, et ils n'ont aucune intention de la mettre à jour.
Si tu regardes comment bosse Mono, ils n'utilisent pas du tout ces normes. Ce qu'ils sont obligé de faire, c'est réaliser des tests sur l'implémentation de MS, et implémenter leur code de façon à ce que ces tests passent. Si tu compares à une implémentation d'un stack réseau ou d'un format de fichier tu vas comprendre qu'il y a un problème.
.Net multiplateforme? Dans un univers parallèle peut être mais dans le monde où je vis ça n'existe pas.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
Non, depuis le départ j'essai de parler d'une seule chose : Qyoto, binding .NET/Mono, Qt.
Les dérives sur la portabilité de l'implémentation propriétaire de la CLI par Microsoft, c'est ton délire et le délire de ____.
'aurais d'ailleurs bien du mal à citer une seule killer app en .Net qui tourne sur Linux et Mac.
Le problème c'est déjà de trouver des killer-app, ensuite de trouver des killer-app qui tournent exclusivement en .NET et sans utiliser de bibliothèques spécifiques à tel ou tel système. C'est le problème des killer-apps, c'est que généralement elles sont bien car intégrés dans leur environnement, et portabilité rime rarement avec intégration parfaite.
Quand on parle de .Net, on parle de l'implémentation de Microsoft.
Je pensais qu'en parlant de Qyoto sur LinuxFR on pouvait ne pas parler de .NET et avoir un débat technique constructif. Visiblement non.
Aucune application .Net n'est venu de Windows vers Linux
Applications graphiques, effectivement non. Mais des libs pleins. Et le but n'est pas seulement de porter des applications, c'est aussi d'attirer des développeurs Windows à l'environnement Linux. Ce fut mon cas, et je suis pas le seul.
Visiblement on trouve beaucoup plus de geeks motivés pour coder des applications desktop sous Linux avec Mono qu'en Java.
Si tu regardes comment bosse Mono, ils n'utilisent pas du tout ces normes.
Ils se basent dessus.
Ce qu'ils sont obligé de faire, c'est réaliser des tests sur l'implémentation de MS, et implémenter leur code de façon à ce que ces tests passent.
Ben c'est indispensable vu que les 3/4 des libs sont pas standardisées. Mais pour ce qui est du coeur, à savoir la CLI, franchement tu vois quoi comme écart notable par rapport à la norme dans les implémentations MS et Mono ?
Si tu compares à une implémentation d'un stack réseau ou d'un format de fichier tu vas comprendre qu'il y a un problème.
Je vois pas de différence. Aucune implémentation d'un standard est exempt de bug et tout le monde cherche naturellement à être compatible avec l'implémentation de référence.
.Net multiplateforme? Dans un univers parallèle peut être mais dans le monde où je vis ça n'existe pas.
Ca tombe bien, on s'en branle, on parle de Mono, CLI, binding Qt.
[^] # Re: Qyoto/Kimono
Posté par Benjamin Poulain (site web personnel) . Évalué à 3.
Il ne me reste qu'à te souhaiter bon courage pour développer des applications multiplateforme avec .Net.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 1.
Je te retourne la critique : moi je chercherais à discuter technique de binding, portabilité, vous préférez troller sur MS.NET.
Désolé de ne pas vouloir troller sur ce que tu veux.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
Relis bien ce que nous avons dit car je crois qu'il y a clairement soit un effort de déformation de nos dire soit un problème interface chaise/clavier. Ni l'un ni l'autre n'avons nié la portabilité théorique mais la portabilité pratique. Qui plus est dans mon cas je précise bien de façon systématique C#/.Net et si j'ai tord donne moi le lien ou je peux récupérer un environnement C#/.Net complet pour Linux. Encore une fois tu mélanges la théorie et la pratique! Et tu commences à me casser les couilles sur le coup à vouloir systématiquement me faire passer pour un taré qui devrait aller dans un asile avec ses "délires"!
Ils se basent dessus.
Et uniquement dessus où ils n'implémenteraient pas aussi des trucs non normalisés?
Visiblement on trouve beaucoup plus de geeks motivés pour coder des applications desktop sous Linux avec Mono qu'en Java.
On ne doit pas vivre dans le même monde car je vois beaucoup plus d'applications java sous linux que d'application mono et c'est assez rassurant de voir ces dernières être remplacé lorsque c'est possible (exemple beagle qui a disparu de l'installation par défaut des distributions).
Ben c'est indispensable vu que les 3/4 des libs sont pas standardisées.
Et tu as du mal à comprendre que certaines personnes n'apprécient pas cela? Tu semble dire d'un côté que C#/.Net c'est normalisé et puis par la suite tu dis que non et tu restreints le tout à CLI que personne dans ce fil n'a dit que ce ne l'était pas... Ce que tu fais c'est noyer le poisson et faire passer une sardine (CLI) pour une baleine (C#/.Net).
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 1.
C'est tout à fait ce que j'ai voulu dire : vous parleinz de MS .NET, c'est votre délire trollesque à tous les 2, et n'insistez pas, ca m'intéresse pas comme débat de discuter d'un produit proprio qui ne tourne que sur des plateformes proprios.
me faire passer pour un taré qui devrait aller dans un asile avec ses "délires"!
Eh ca m'arrive de délirer sans aller à l'asile :) Sérieux, je passe mon temps à essayer de recadrer le débat sur la partie technique normalisée, la CLI, qui m'intéresse et intéresse sans doute du monde sur LinuxFR parcqu'implémenté par Mono et Portable .NET. T'as visiblement qu'un objectif : discuter des produits commerciaux de Microsoft et de ses problèmes spécifiques, va sur windowsFR si ca existe, mais moi ca m'intéresse pas.
On ne doit pas vivre dans le même monde car je vois beaucoup plus d'applications java sous linux que d'application mono
Oué chacun son desktop effectivement. Moi mon Ubuntu avec son environnement de base, cad Gnome, vient avec F-Spot, Banshee et Tomboy. Sans chercher à faire de comparaison avec Java, ca reste que des développeurs ont visiblement trouvés un intérêt à coder des applications avec mono, et les utilisateurs ont trouvés suffisament d'intérêts dans ces applications pour qu'elles soient utilisées dans une distribution populaire. Bref, mono n'a plus à démontrer son intérêt.
Et tu as du mal à comprendre que certaines personnes n'apprécient pas cela?
A part les gens qui codent pour un produit proprio (MS.NET) sur une plateforme proprio (Windows), ca gène qui sous Linux ?
Tu semble dire d'un côté que C#/.Net c'est normalisé
Y'a la base technique et j'ai jamais dis autre chose : la VM et les libs de base. C'est absolument tout ce qui nous intéresse dans le débat technique de Qyoto.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 0.
Je sais la première que je fais c'est justement de dégager ce merdier. De tout de façon Digikam est mieux que F-Spot (à mon avis), Banshee (non installé par défaut à moins que cela ait changé dans intrepid) c'est pas mieux que amarok et de tout de façon j'utilise mpd et quand à tomboy je ne vois pas trop ce que cela apporte par rapport à basket tellement c'est basique.
Bref, mono n'a plus à démontrer son intérêt.
Son intérêt peut être pas mais par contre son danger si. Je me demande pourquoi Novell a passé un accord avec Microsoft si c'était si sécure que cela sinon... Juste pour se mettre une partie de la communauté à dos?
T'as visiblement qu'un objectif : discuter des produits commerciaux de Microsoft et de ses problèmes spécifiques, va sur windowsFR si ca existe, mais moi ca m'intéresse pas.
TU es le premier de nous deux à avoir parlé de Microsoft alors rendons à César ce qui est à César ne te plains pas après de te voir ce genre d'argument utilisé dans le sens oposé de tes désirs (comme si cela était une surprise sur ce site qui plus est...). Que veux tu que j'aille foutre sur windowsFR? Je ne me sers plus de cet OS (à mon grand plaisir) depuis des années et je ne suis pas comme certains je vais pas ramener ma fraise la où elle n'a rien à faire.
Y'a la base technique et j'ai jamais dis autre chose : la VM et les libs de base. C'est absolument tout ce qui nous intéresse dans le débat technique de Qyoto.
La base technique de la version 2 car la version 3 n'est pas normalisé donc vers quoi doit se faire le bindings? Une version obsolète ou une version non normalisé? Et comme dit auparavant si tu n'est pas content des bindings Qt pour C# fait les, le code est opensource.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 3.
troll FUD patent detected. bip bip.
L'accord concerne pas uniquement mono mais tous les logiciels inclus dans les distributions Linux de Novell.
Si tu parles du récent accord, il concerne moonlight, qui par nature intègre du code à Microsoft : les foutus codecs bourrés de brevets (et pas uniquement des brevets de MS). Mais c'est pas le sujet, Moonlight ne m'intéresse pas, et n'a vraiment aucun rapport avec ce Qyoto.
Juste pour se mettre une partie de la communauté à dos?
Je suppose que dans la tête des commerciaux de Novell, ca rassure les clients, quitte à se mettre à dos la communauté. Je dis pas que c'est malin mais je suppose que c'est le raisonnement.
Je ne me sers plus de cet OS (à mon grand plaisir) depuis des années et je ne suis pas comme certains je vais pas ramener ma fraise la où elle n'a rien à faire.
Eh ben c'est parfait ! t'en à rien à branler de MS.NET alors ! Rien à péter du retard de Mono sur la compatibilité avec les libs de .NET ! Rien à péter des bindings Qt proprios pour COM/.NET ! Que du bonheur, on va enfin pour en revenir à ce qui nous intéresse, Qt open source et le binding Qyoto !
La base technique de la version 2 car la version 3 n'est pas normalisé
Ce qui est chiant, c'est que tu trolls en même temps que tu découvres de quoi tu parles. Le socle technique n'a pas bougé depuis 4 ans et est toujours en version 2.0. Son implémentation dans mono est stable depuis un bon moment, la norme ISO est toujours d'actualité, tout va bien.
Le socle technique s'appelle CLI pour Common Language Runtime, autrement dit, rien à péter de la version de C#, de VB ou d'IronPython au dessus, si tu fais un binding pour la CLI, c'est un problème parfaitement indépendant du langage, la CLI a été conçu pour ça.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
voyons tu sais bien que mono a bien été mis en avant au moment de l'accord.
Rien à péter du retard de Mono sur la compatibilité avec les libs de .NET
Sauf si les cas comme celui du portugal se généralise.
Si tu parles du récent accord, il concerne moonlight, qui par nature intègre du code à Microsoft
Ah ben c'est encore pire que je croyais...
Ce qui est chiant, c'est que tu trolls en même temps que tu découvres de quoi tu parles.
Excuse moi de ne pas être spécialiste de mono et de te laisser nous parler de ta spécialité...
Il est vrai que je ne connais pas le sujet mais d'après la FAQ The Mono API today is somewhere in between .NET 2.0 and .NET 3.5 donc il semblerait bien qu'il y ait pas mal de chose non normalisé dans le framework qui si j'ai bien compris comprend un tout petit peu plus que CLI... Enfin pour en revenir au sujet Qt a un bindings que tu n'aimes pas la façon dont il fait c'est pas trop un problème tu n'as qu'à le faire proprement toi même. Vive les logiciels opensource pour cela!
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Qyoto/Kimono
Posté par Alexis Ménard (site web personnel) . Évalué à 6.
Mais tout Qt est fait en C++, je pense pas que tu te rends compte de la masse de travail que c'est de faciliter la taches de binders en ayant une autre API, et la maintenance.
Qt est un produit en C++. Nokia développe son produit qui est Qt. PyQt et co sont d'autres produits. C'est pas le rôle de Nokia de faire ça, de faciliter le binding puisque a la base le produit Qt est fait en C++. Les gens se sont lances dans des bindings, très bien mais on peut pas demander a Nokia de supporter un truc qu'il ont pas décide, supporte, voulu.
Et puis honnêtement pourquoi se faire chier a faire des APIs pas géniale pour matcher avec des langages comme C et faciliter le binding. On en veut pas, si c'est pour se retrouver avec des APIs a la GTK ma_fct_qui_s_appelle_super. Non merci!!!! Et puis chaque langage est spécifique ça deviendrai l'usine a gaz.
qui conseille dans la doc des solutions proprio comme s'il existait que des CLI proprios sous un OS proprio
Ils te conseillent pas de l'utiliser bien évidemment.
"Qt's ActiveX and COM support allows Qt for Windows developers to:"
Je pense que la phrase est claire que ca tue le cross platform de ton appli. Ils supportent pas les autres plate-formes (même si y'a Mono sous linux dans l'absolu), c'est juste pas teste. Il a jamais été marque qu'il faut l'utiliser, c'est un hack pour certaines applis Windows qui veulent du .Net/COM et co.
Mais c'est pareil dans tous langages, si on s'appui par exemple sur des libs spécifiques à une plateforme, c'est pas portable. On trouve une palanquée de libs sous Linux qui ne sont pas portées sous Windows par exemple.
Tu t'égares la. Un langage ne s'appuie pas sur des librairies , ERREUR. Un langage peut parfois fournir une librairie (exemple la std que tu dois implémenter sur ta plate-forme si tu veux qu'elle soit C++ compliant). Un framework utilise des librairies.
.Net n'est pas un langage mais un framework qui s'appuie entre autre sur le C# et des librairies (non portables pour certaines).
Qt est un framework aussi s'appuyant sur le langage C++ utilisant des libs mais dont Nokia s'assure qu'elles sont cross platform.
Un langage tu peux écrire la grammaire sans même parler de OS, librairies ou architecture.
On peut écrire la grammaire de Java, C++, C, C#.
Mais hélas pour le C# la frontière devient mince avec le langage proprement parle et un framework. C# inclue désormais tout un tas de concept qui ne collent plus avec l'idée originale et qui en vient a utiliser des libraires. Ex : Linq, syntaxiquement très étrange dans un langage et absolument pas implementable facilement sur nunux.
Donc oui dans l'absolu ActiveQt pourrai dire, ah mais sous Nunux tu as Mono ca marche. C'est tout simplement pas supporte et teste, pas dans les priorité de Nokia (ce que je comprends) et de plus tu n'as aucun contrôle puisque c'est un autre framework.
Supposons que sur mon appli Qt avec ActiveQt sous Windows, je fais du C# .Net avec fct A du framework 3.5. Niquel ca marche. Ah c'est Qt cross platform il disent mono sous linux parfait je recompile sous Nunux et la ça se branche sur Mono mais la fct A est pas implémenté, Craboum. Problème. Je comprends parfaitement que ça soit pas mis en avant car pas supporte et de plus c'est un hack, c'est une feature qui est que pour Windows dans des cas très précis (interfacage) et pour des raisons historique (des clients ont du demander) et cela est absolument pas garanti cross plate-forme. En fouillant un peu tu trouvera des features non cross platform dans Qt, mais le manuel dit : "Utilise les a tes risques et peril".
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
C'est tout le problème de la philosophie Qt. Si tu veux pas faire de C++, ben pas d'bol, t'es considéré comme un développeur de seconde zone.
C'est effectivement un choix de Nokia, ils font comme ils veulent, je trouve ca juste dommage, je peux ?
Ils te conseillent pas de l'utiliser bien évidemment.
"Qt's ActiveX and COM support allows Qt for Windows developers to:"
Comme déjà dis, ils le conseillent officiellement, et j'ai rien vu concernant la portabilité, notamment dans la section limitation, sur la page concernée :
http://doc.trolltech.com/4.5/activeqt-dotnet.html
On est quand même en droit de trouver ca dommage de conseiller d'utiliser un truc pas portable avec un framework portable non ?
Un langage ne s'appuie pas sur des librairies , ERREUR.
T'es comique, tu cites juste LINQ qui est le parfait contre exemple de ce que tu dis :)
Enfin quand je disais langage, je parlais de plateforme, on se comprend.
Linq, syntaxiquement très étrange dans un langage et absolument pas implementable facilement sur nunux.
Etrange ou innovant ? Moi je trouve ca génial à l'utilisation : ca pousse à écrire du déclaratif / fonctionnel plutôt que l'impératif classique, et je trouve ca pas plus mal.
Quand à la difficulté d'implémentation sous Linux, laisse moi rire, Mono l'implémente très bien C# 3.
Supposons que sur mon appli Qt avec ActiveQt sous Windows, je fais du C# .Net avec fct A du framework 3.5.
ActiveQt est une interface COM, technologie vieille de 10 ou 20 ans, qui tourne concrêtement que sous Windows aujourd'hui. C'est pas un problème de .NET Mono ou autre. C'est un problème de portabilité de ActiveQt en soit, qui fait que ce n'est une solution utilisable que sous Windows.
En fouillant un peu tu trouvera des features non cross platform dans Qt, mais le manuel dit : "Utilise les a tes risques et peril".
Mais je suis d'accord avec ca, je critique pas le fait que y'es des trucs pas cross-plateforme par ci par là, ce que je critique c'est le manque de considération général pour les autres plateformes/langages que C++. C'est dommage c'est tout.
[^] # Re: Qyoto/Kimono
Posté par Benjamin Poulain (site web personnel) . Évalué à 2.
Essaye PyQt, tu verras si Qt ne tourne correctement qu'avec C++. L'intégration à Python est nickel.
Je peux dire la même chose pour Qt Jambi.
Et dans une certaine mesure j'aime bien aussi Qt Script, qui n'est jamais que du Javascript pour Qt.
Mais oui, peu de gens aiment .Net, et du coup les bindings sont pas terrible parce que personne n'a envie de bosser pour cette plateforme. Bienvenu dans le monde réel.
[^] # Re: Qyoto/Kimono
Posté par sanao . Évalué à 6.
Et encore c'est parce que l'interface est la première chose qui me vient à l'esprit. Mais quelqu'un plus au fait de la question devrait me donner tout une liste de trucs qui sont spécifiques Windows et pourtant généralement essentiel lors du développement d'une application.
Que le langage soit très bien, que l'adaptation de Mono soit très bien pour développer des applications je n'en disconvient pas (eu égard des commentaires de développeurs et des quelques applications que j'ai pu voir). Mais il faut arrêter de dire que ce que pond Microsoft est portable. L'API n'est généralement pas portable et spécifique sur bien des points à Windows.
Ce qui est relativement portable c'est Mono, pas le .Net de Microsoft.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 4.
- une raison technique : certains API s'appui sur des libs Windows et sont donc difficilement portable. Mais c'est pareil dans tous langages, si on s'appui par exemple sur des libs spécifiques à une plateforme, c'est pas portable. On trouve une palanquée de libs sous Linux qui ne sont pas portées sous Windows par exemple. Après ca ne concerne pas grand chose dans .NET, voir quasiment rien. Le problème est ailleur, voir ci-dessous.
- une raison commerciale : la licence de l'implémentation de .NET ne permet pas de réutiliser les composants sur autre chose qu'un OS Windows. Ca pu c'est pas libre. C'est pas pour ca que c'est pas portable. Et c'est ce que fait Mono : elle propose une implémentation alternative libre sans limitation de plateforme.
Mais techniquement je le répète, le socle technique de .NET/Mono est parfaitement portable. Y'a une abstraction de tout : les instructions machines, la mémoire, les threads, etc.
Et c'est bien de technique dont on parle ici quand on parle de binding. Et on est sur LinuxFR, donc on s'intéresse à Mono, qui est une plateforme portable ET portée.
[^] # Re: Qyoto/Kimono
Posté par sanao . Évalué à 2.
En fait l'article c'est sur Qt (c'est juste pour avoir le fin mot de l'histoire!)
Mais je suis d'accord sur le principe : Mono est portable. Mais le .Net que fournit Microsoft ne l'est pas car trop lié à Windows. Maintenant l'utilisation de .Net dans Qt n'est pas destiné à ceux qui veulent être portable, mais bien à ceux qui développent pour Windows avec Qt en voulant s'interfacer avec du .Net sous Windows.
Si Qt le propose, c'est qu'il y a un besoin et ActiveQt est là pour y palier.
PS : En tout cas j'ai l'impression que l'on a un nouveau troll : Qt vs Mono. A moins qu'il existait déjà...
[^] # Re: Qyoto/Kimono
Posté par Kangs . Évalué à 1.
[^] # Re: Qyoto/Kimono
Posté par Kangs . Évalué à 1.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 5.
Par exemple pour la bibliothèque sqlite, qui est une lib qui expose "correctement" ses API binaires, le binding .NET/Mono est écrit en C# et est parfaitement portable (même pas besoin de recompiler, juste à s'arranger pour qu'il y est sqlite.so à la place de sqlite.dll).
Mais tout ca suppose des API binaires portables et standardisés, ce que n'offre pas C++ avec son foutu nommage à la con des méthodes.
http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_(...)
[^] # Re: Qyoto/Kimono
Posté par Kangs . Évalué à -4.
Ca ce passe de commentaire...
>Par exemple pour la bibliothèque sqlite, qui est une lib qui expose "correctement" ses API binaires, le binding .NET/Mono est écrit en C# et est parfaitement portable (même pas besoin de recompiler, juste à s'arranger pour qu'il y est sqlite.so à la place de sqlite.dll).
Tu dis vraiment n'importe quoi.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par GeneralZod . Évalué à 4.
Faut le reconnaitre, Timaniac marque un point.
Invoquer du code natif en Mono avec P/Invoke c'est nettement plus simple que de passer par la JNI. D'ailleurs, la communauté Java a fini par pondre JNA (Java Native Access) qui s'inspire ouvertement des P/Invoke mais également ctypes (Python).
Un billet que j'ai lu il y a un moment et qui résume bien pourquoi JNI sapugrave.
http://www.koushikdutta.com/2009/01/jni-in-android-and-forew(...)
[^] # Re: Qyoto/Kimono
Posté par Alexis Ménard (site web personnel) . Évalué à 5.
Si y'a moyen de faire de l'ActiveQt c'est pour certaines applis sous Windows et SEULEMENT sous Windows qui veulent bricoler du .Net. C'est purement pour faire parfois parler des applis .Net avec des applis Qt.
Ah oui et je rappelle que ActiveQt ou ce que c'etait avant existe depuis 2002 bien avant Mono (avec COM, MFC et co). Donc aucun rapport avec Mono.
Utiliser ActiveQt c'est comme avoir un XPixmap dans son code tu tue le cross-platform de ton applis. Après a coup de ifdef tu peux t'en sortir. Tu te plains de la doc qui prône le fait que ça soit crado mais bon c'est pour ça que tu as Qt, pour pas utiliser .Net et son implémentation incomplète sur Linux avec Mono.
Qt a ses avantages et ses défauts (binaire pas facilement deployable sur certaines archi par exemple).
Honnêtement je pense pas que c'est dans le scope de Qt de s'occuper de ce genre de bindings. Laissons la communauté le faire si ils ont besoin et le veulent. Je trouve que c'est juste inutile mais c'est mon avis.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais Nokia pourrait tout de même faire un truc de base qui intéresserait tout le monde : un binding C officiel et maintenu. Ca simplifierait les bindings dans tous les langages.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à -1.
D'où l'idée d'utiliser des frameworks comme Qt dont l'implémentation de référence elle-même est portable.
Ca marche très bien avec GTK+mono, parcque l'implémentation de référence de GTK est portable.
[^] # Re: Qyoto/Kimono
Posté par alice . Évalué à 4.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Qyoto/Kimono
Posté par Larry Cow . Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par Anonyme . Évalué à 1.
# Qt Extended abandonné à son tour
Posté par soulflyb (Mastodon) . Évalué à 3.
Il semble donc que Nokia fasse le ménage dans ses plateformes pour embarqué, mais entre Maemo, Symbian et Qt extended, il aurait peut-être fallu en supprimer une autre ...
[^] # Re: Qt Extended abandonné à son tour
Posté par Gof (site web personnel) . Évalué à 6.
En gros, depuis quelques années déjà, le code utile de Qtopia est déplacé progressivement dans Qt lui-même (Qt Embedded Linux, ...)
Avec Qt Embedded Linux, Qt Windows CE, Qt S60. Cela fait 3 platforme de dev pour l'embarqué pris en charge par Qt
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.