Articles précédents : Développeur
- [0] Nouvelles rencontres forges logicielles à Paris
- [102] Btrfs intègre le noyau Linux dès la prochaine version 2.6.29
- [85] L'évolution de Fastboot
- [50] AMD continue l'ouverture des spécifications de GPU
- [11] Naissance d'un projet libre : Pharo
- [23] Emtec lance le programme One Laptop Per Hacker
- [27] Waf - un système de construction de logiciels
- [12] Coding Dojo à Grenoble
- [17] Portage de GNewSense sur MIPS
- [19] Nouvelle version CodingTeam estampillée 0.9
Liens connexes
- Rachat de Trolltech par Nokia sur DLFP (239 hits)
- Annonce officielle (323 hits)
- Ars Technica : Nokia Qt LGPL switch huge win for cross-platform development (201 hits)
- Qt Labs Blog : Sebastian Nyström Qt KDE News Nokia to license Qt under LGPL (198 hits)
- DLFP : Nokia rachète Trolltech (261 hits)
- DLFP : Nokia rachète Symbian (269 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Qt 4.5 sera sous licence LGPL 2.1
Posté par Pinaraf (Jabber id, ). Modéré le 14 janvier 2009.Rappel : Qt est la bibliothèque de base de l'environnement graphique KDE, programmée en C++ et disponible sur la majorité des plate-formes du marché (X11, Microsoft Windows, MacOS X, en embarqué via Qtopia sur GNU/Linux ou encore Windows CE…).
NdM : signalons aussi que la bibliothèque GTK+, considérée comme l'autre grande bibliothèque graphique, est également sous licence LGPL 2.1. Et merci à GeneralZod qui a aussi proposé une dépêche sur le sujet.
Rachat de Trolltech par Nokia sur DLFP (239 hits)
Annonce officielle (323 hits)
Ars Technica : Nokia Qt LGPL switch huge win for cross-platform development (201 hits)
Qt Labs Blog : Sebastian Nyström Qt KDE News Nokia to license Qt under LGPL (198 hits)
DLFP : Nokia rachète Trolltech (261 hits)
DLFP : Nokia rachète Symbian (269 hits)
> Lire la suite (85 commentaires, moyenne: 3). [dépêche : 1955 caractères]
GeneralZod ajoute :
«
Cette décision est parfaitement cohérente avec la stratégie globale de Nokia de créer un ensemble de briques libres pour l'industrie dont Symbian et Qt sont les fers de lances.
Le rachat puis la libération de Symbian ont permis à Nokia d'avoir une offre logicielle concurrente viable face aux plateformes mobiles Android, LiMo, OpenMoko et les propriétaires Windows CE, iPhone OS tout en redynamisant le développement de celui-ci.
La place de Qt dans tout ça est d'offrir un framework de développement multiplateforme permettant de supporter avec le même code source (ou presque) la plupart des environnements cités précédemment.
Cela est confirmé par les portages de Qt vers Windows CE, S60, la mise en avant de Qt Extended (ex-Qtopia, plateforme embarqué basé sur Linux), l'intégration de composants tels que WebKit (moteur de rendu web), Phonon (framework multimédia), QtAnimation (framework d'animation repoussé à Qt 4.6 mais également disponible séparément).
Qt 4.5 sera accompagné d'un RAD multiplateforme Qt Creator (actuellement en béta), Nokia met clairement le paquet pour faire de Qt LA plateforme de référence pour le développement d'applications mobiles et sur le desktop.
»
Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Je me suis fait doubler pour ma dépêche, voilà le texte comme ça ce n'est pas perdu:
Qt_Software (anciennement Trolltech) a annoncé aujourd'hui que la prochaine version de Qt vera l'ajout de la licence LGPL v2.1. L'annonce indique aussi qu'un nouveau mode de développement sera bientôt mis en place, permettant des contributions directes au dévelopement de Qt.
Pour rappel, Qt est un framework multi-platforme qui facilite la création d'applications de bureau. Ce framework est connu pour être à la base de KDE mais il est aussi utilisé dans de nombreux projets hors KDE (VLC, Skype, Google Earth, etc).
À partir de la version 4.5, qui devrait sortir en mars, Qt sera sous triple licence: LGPLv2.1, GPLv3 et commerciale. L'ajout de la licence LGPL vient apporter un changement fondamental pour les développeurs qui commercialisent une version fermée de leur logiciel, il leur sera désormais possible d'utiliser Qt sans payer de licence.
La licence GPL devrait rester la licence la plus populaire pour les projets libre mais il est probable que de nombreux projets adopteront la LGPL à cause de leur modèle de distribution (Mozilla Firefox par exemple).
Qt Software prévoit aussi d'ouvrir le développement de Qt. Il sera bientôt possible de contribuer directement à la base de code de Qt. Ce changement risque d'être déterminant pour la réactivité de correction de bugs, et les nouvelles fonctionnalités de la bibliothèque.
Avec ce changement de licence, Nokia espère multiplier le nombre de dévelopeurs utilisant Qt. Plus de développement sur Qt devrait amener plus d'application (commerciale ou libre) sur Linux. De nombreux client de Nokia ont choisissent Qt pour la facilité de développement sous Windows ou Mac, et fournissent finallement un version Linux de leurs logiciels.
La licence commerciale est conservée pour les développeurs d'application qui ne souhaitent pas se soumettre aux obligations de la LGPL. Et Nokia continuera à vendre du support.
Concernant l'ouverture du mode de développement, peut d'informations sont encore dévoilées. D'après le site web, les dépots seront ouverts (probablement comme on a pu le voir avec Qt creator).
On a pu voir une intenssification du dévelopement avec Qt 4.5, et il est probable que l'ouverture des dépots accellerera encore les choses. La FAQ indique aussi que ces changements visent aussi à améliorer encore la qualité de Qt.
La licence des version de Qt inférieure à 4.5 restera inchangée.
http://www.qtsoftware.com/about/news/lgpl-license-option-add(...) Annonce officielle
http://dot.kde.org/1231920504/ Annonce de KDE
http://www.qtsoftware.com/about/licensing/frequently-asked-q(...) FAQ
http://aseigo.blogspot.com/2009/01/qt-goes-lgpl.html Blog du président de KDE eV
http://labs.trolltech.com/blogs/2009/01/14/nokia-to-license-(...) Blog du dirrecteur de Qt Software
Visitez Linux Certif, le site qu'il est bien pour les Linuxiens. (Passez voir aussi OpenYourCode pour les développeurs)
-
[^]Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par vida18 () le 14/01/2009 à 12:51. (lien). Évalué à 3.Pourquoi utiliser une triple licence: LGPLv2.1, GPLv3 et commerciale et pas juste une double licence LGPLv2.1/commerciale ?
-
[^]Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par Zenitram (page perso, ) le 14/01/2009 à 13:32. (lien). Évalué à 3.et pas juste une double licence LGPLv2.1/commerciale
Comme ça ceux ayant leur code en GPLv3 et linkant habituellement en statique l'ont dans l'os, sympa pour eux.
Quand Qt sera releasé en LGPLv2.1 ET v3, ils enlèveront la GPLv3 (comme ils enlèvent la GPLv2 car il y a las LGPLv2 maintenant), mais avant qu'ils le fassent je ne vois pas pourquoi on devrait empêcher les développeur en GPLv3 de continuer.-
[^]Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par vida18 () le 14/01/2009 à 14:27. (lien). Évalué à 3.Je dis ça parce que s'il avait choisi LGPL v2.1 ou plus/commerciale ça aurait aussi été compatible avec la GPL v3.
-
[^]Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par Anacr0x (page perso, ) le 14/01/2009 à 15:15. (lien). Évalué à 2.pour une liaison dynamique oui, il ne me semble pas que ça soit le cas pour une liaison statique.
-
[^]Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par Zenitram (page perso, ) le 14/01/2009 à 16:06. (lien). Évalué à 2.LGPLv2.1+ --> LGPLv3+ --> GPLv3+
Donc OK pour une liaison statique avec du code GPLv3(+) car même licence.
Mais Qt sera en LGPLv2.1 donc pas possible.
-
-
-
[^]Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par Nicolas Legrand () le 14/01/2009 à 17:23. (lien). Évalué à 2.Hein ? Du code GPL3 dans l'OS ? Moi qui croyait que linux restait en GPLv2.
-
-
Ha zut...
Heureusement, il reste de bon vieux trolls bien poilus et indestructible.
Vi rules, Emacs sucks!
A vous :D
Plus sérieusement, ce passage sous LGPL est une bénédiction pour les microISV/startups qui ne peuvent se payer la licence pour chaque développeur, même si ladite licence n'est pas si chère comparée au gain de productivité obtenu avec Qt.
-
[^]Re: Ha zut...
Posté par windu.2b (Jabber id, page perso, ) le 14/01/2009 à 12:02. (lien). Évalué à 4.Ou tout simplement (pour rester dans le débat autour de Qt) :
"Gnome ça pue y a qu'un bouton, KDE ça roxxxe y a plein d'options partout !"-
[^]Re: Ha zut...
Posté par LupusMic (page perso, ) le 14/01/2009 à 15:12. (lien). Évalué à 1.Il reste toujours le très classique « Qt ça pue, c'est pas du vrai C++ » :D
-
[^]Re: Ha zut...
Posté par Larry Cow () le 14/01/2009 à 16:37. (lien). Évalué à 3.Pour certains, ne pas être du vrai C++ est plutôt une qualité. Enfin pour tout le monde, en fait, à l'exception des "vrais" pluspluseurs, pour qui un bon programme est un programme fait à plus de 95% de templates :)
-
[^]Re: Ha zut...
Posté par Luc Hermitte (page perso, ) le 14/01/2009 à 19:20. (lien). Évalué à 2.Le but n'est pas d'augmenter la quantité de template, mais d'augmenter la quantité de RAII pour réduire, entre autres, la quantité de pointeurs (bruts).
-
-
[^]Re: Ha zut...
Posté par sanao () le 14/01/2009 à 16:40. (lien). Évalué à 2.Regarde après le traitement du moc, c'est bien du vrai C++ (d'ailleurs G++ ne s'en plaint pas). Le moc est juste là pour permettre au développeur de coder certaines choses plus clairement et simplement.
Comment ça j'ai marché dedans!-
[^]Re: Ha zut...
Posté par syj () le 14/01/2009 à 22:15. (lien). Évalué à 2.Le seul truc que je me souviens de Qt et de KDE.
C'est le temps de compilation pour un pauvre projet qu'on avait délloppé.
Le passage pré-processor qui génère plein de ligne de code , çà me fait penser à la news/fiction sur le développement LFR en J2EE.
Enfin ,je dis çà mais çà a probablement changé. C'était à l'époque de QT 2...
PS: Mince, moli aussi j'ai marché dedans.-
[^]Re: Ha zut...
Posté par koopa () le 15/01/2009 à 09:10. (lien). Évalué à 3.Dans un projet QT tu as interet à utiliser des headers precompilés sinon effectivement les temps de compilation peuvent devenir abominables.
Mais avec les headers precompilés (pour éviter de reparser et les temps de compilations redeviennent raisonnables.
Dans ton fichier .pro, il suffit d'ajouter:
CONFIG += precompiled_header
PRECOMPILED_HEADER = mon_fichier_entete.hpp
-
-
-
[^]Re: Ha zut...
Posté par Claude Computing () le 14/01/2009 à 16:45. (lien). Évalué à 4.Oui mais le C++ c'est pas du vrai C.
-
[^]Re: Ha zut...
Posté par vincent_k (Jabber id, page perso, ) le 14/01/2009 à 18:18. (lien). Évalué à 2.Et le C, c'est pas de l'assembleur
-
-
-
Version
LGPL 2.1 et pas 1.2, si ? (dans le texte et le titre)
-
[^]Re: Version
Sauf que ...
sous la licence LGPL 1.2. Cela permettra donc par exemple de réaliser des applications propriétaires utilisant Qt sans devoir pour autant disposer d'une licence commerciale de Qt
La LGPL ne semble pas être très appréciée par les vendeurs de logiciels propriétaires (contrairement aux BSD, Apache et autres MIT).
Du moins c'est ce que je constate dans le monde Java (oui ce n'est pas le sujet ici).
Et ne me demandez pas pourquoi le sujet semble complexe, en tout cas trop pour moi :-)
-
[^]Re: Sauf que ...
Posté par GeneralZod () le 14/01/2009 à 12:01. (lien). Évalué à 3.Pour la plupart des entreprises, la licence LGPL passe relativement bien. Contrairement à Qt Extended, très peu d'entreprises ont besoin de patcher Qt, et encore moins ont d'intérêts à ne pas publier ses patchs.
Pour les plus réfractaires, Qt offre toujours une licence commerciale.
Personnellement, je suis curieux de savoir si Qt Software compte libérer tout les add-ons (notamment ActiveQt, ou bien l'intégration à Visual Studio), qui propulserait encore plus l'adoption de Qt.-
[^]Re: Sauf que ...
Posté par trois_1 () le 14/01/2009 à 14:59. (lien). Évalué à 2.Qt Extended ne passe pas LGPL d'apres la FAQ:
Does the licensing change apply to Qt Extended?
No, the licensing change does not apply to Qt Extended.
Vous etes bien d'accord avec moi? contrairement à ce qui est écrit dans la dépèche....
Pour une entreprise qui fait de l'embarqué par QT Extended en LGPL, est-ce la seule contrainte est le non-support et la diffusion des modifs de QT Extended?
-
[^]Re: Sauf que ...
Posté par Jérôme () le 14/01/2009 à 16:05. (lien). Évalué à 2.Je précise ce que je voulais dire.
Dans le monde dans lequel je bosse (Java donc), j'ai l'impression que la licence LGPL n'est que très rarement acceptée par les éditeurs de propriétaire, y compris quand ils ne font qu'utiliser, et ne modifie pas la librairie.-
[^]Re: Sauf que ...
Posté par GeneralZod () le 14/01/2009 à 16:15. (lien). Évalué à 1.C'est effectivement étrange, pourquoi ce refus de la LGPL ? Confusion avec la GPL ? frilosité ? absence de support ?
-
[^]Re: Sauf que ...
Posté par Jérôme () le 14/01/2009 à 16:37. (lien). Évalué à 3.Je réponds par la même occasion à trois_1 qui pose une question similaire en dessous.
Je pense que c'est principalement du à une mauvaise compréhension de la LGPL.
Les éditeurs de logiciels proprio sont très frileux (du moins leurs avocats) quant aux impacts que peut avoir la licence d'une bibliothèque utilisée sur l'ouverture ou non de leur code. Et sur l'impact que cela peut éventuellement avoir sur le code de leurs clients.
On va dire qu'ils préfèrent prévenir que de se taper des complications.
La LGPL en fait les frais à cause de l'ambiguité qu'il y a eu à une certaine époque sur la notion de "lien" qui est plutôt claire en C ou C++ par exemple mais pas en Java.
Même si il y a eu des précisions depuis ça reste dans l'air.
De plus je viens de jeter un oeil à http://www.gnu.org/licenses/lgpl-java.fr.html pour avoir plus d'infos.
Et quand je lis :
Les applications ne doivent suivre que les conditions de la section 6 de la LGPL : autoriser de nouvelles versions de la bibliothèque à être liées avec l'application et de permettre la rétro-ingénierie pour déboguer cela.
Je ne m'étonne pas que les éditeurs de proprios ne soient pas très chauds pour autoriser la rétro-ingénierie de leurs produits.
La licence Apache (au hasard) n'a pas ce genre de contraintes ou d'ambiguités.
J'espère que ça vous éclaire un peu sur mon contexte :-)-
[^]Re: Sauf que ...
Posté par baud123 (Jabber id, page perso, ) le 14/01/2009 à 17:36. (lien). Évalué à 2.Je ne m'étonne pas que les éditeurs de proprios ne soient pas très chauds pour autoriser la rétro-ingénierie de leurs produits.
Ah bah ils arrêtent de distribuer en France alors ? Parce qu'en France, il est encore autorisé de procéder à de la rétro-ingénierie à des fins d'interopérabilité. Les clauses l'interdisant sont illégales et sautent d'elles-mêmes...-
[^]Re: Sauf que ...
-
-
[^]Re: Sauf que ...
Posté par trois_1 () le 14/01/2009 à 17:40. (lien). Évalué à 1.Auriez-vous une explication sur ce que j'ai noté avec Qt extended (ex-QTopia)??
Est-ce aussi LGPL?-
[^]Re: Sauf que ...
Posté par Philippe Fremy (page perso, ) le 15/01/2009 à 11:26. (lien). Évalué à 1.Ils se gardent une source de revenu. Si tu veux mettre du Qt Extended dans ton téléphone, il faut négocier avec Qt Software. Cela dit, aujourd'hui, la plupart des matériels n'ont plus besoin de la version extended.
-
[^]Re: Sauf que ...
-
-
-
[^]Java par définition s'est Open Source
Posté par syj () le 14/01/2009 à 22:28. (lien). Évalué à 1.Java :proprietaire ou non.
Si tu veux faire de la rétro-ingénierie. Tu n'es pas trop ennuyer.
Un programme qui a même été brouillé reste très lisible.
Il suffit de partir du mapping sur un SGBDR. Tu utilises outil qui te permet du refactoring dans tous les sens et le tour est joué.
En plus, si l'éditeur a utilisé des lib qui utilise la réflexivité dans tous les sens (Hibernate, Struts, Tags jsp). Une grande partie des méthodes ne seront pas brouillé.
Bref un programme Java, c'est par définition Open Source.
A côté un programme PHP peux être vraiment illisible(... même sans le passage par le brouilleur).-
[^]Re: Java par définition s'est Open Source
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 15/01/2009 à 09:15. (lien). Évalué à 3.Un programme java peu tout aussi bien être codé avec les pieds qu'un programme PHP et inversement.
Rien ne m'empêche de placer du html au milieu de mon code java en mélangeant tout au total méprit du sacro saint MVC.
Avoir le bytecode d'un code propre, ce n'est pas de l'OpenSource, qui à une définition précise.-
[^]Re: Java par définition s'est Open Source
Posté par syj () le 16/01/2009 à 09:04. (lien). Évalué à 2.> Avoir le bytecode d'un code propre, ce n'est pas de l'OpenSource, qui à une définition précise.
Ce n'est pas un critique sur le langage que je soumettais même si j'en pense pas moins.
Il existe des brouilleurs automatique de code PHP qui peuvent rendre le code réellement illisible.
Il te sera au final plus facile de faire du reverse sur code Java que sur un code PHP.
- Le nom typage des variables.
- L'interprétation dynamique
aide beaucoup pour réaliser un bon brouilleur.-
[^]Re: Java par définition s'est Open Source
Posté par windu.2b (Jabber id, page perso, ) le 16/01/2009 à 09:22. (lien). Évalué à 5."Il existe des brouilleurs automatique de code PHP qui peuvent rendre le code réellement illisible."
Ça s'appelle un pisseur de code
-
[^]Re: Java par définition s'est Open Source
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 16/01/2009 à 10:16. (lien). Évalué à 4.Oui si tu veux mais si tu dois faire reverse, c'est par définition que tu n'as pas les sources et que ça n'est donc pas OpenSource. C'était là le fond de ma remarque.
-
[^]Re: Java par définition s'est Open Source
Posté par CrEv (page perso, ) le 16/01/2009 à 14:14. (lien). Évalué à 5.> brouilleurs automatique de code PHP qui peuvent rendre le code réellement illisible.
je croyais que c'était intégré en standard...
-
-
-
-
-
-
[^]Re: Sauf que ...
-
-
-
[^]Re: Sauf que ...
Posté par Florimond () le 14/01/2009 à 12:19. (lien). Évalué à 1.expliquez moi, je suis pas très familier avec toutes ces histoires de de licences...
donc avant, un mec qui voulait faire un programme propriétaire (donc ne fournissant pas ses sources, mais pas nécessairement payant) devait payer une licence
maintenant, on peut faire un programme proprio et le vendre sans payer de licence? ou la gratuité est valable seulement si tu ne fais pas de pognon avec... (parce que ça me semblerait normal que si quelqu'un veut faire du pognon avec ton travail... qu'il te remercie de ton travail par une petite dringuelle!)-
[^]Re: Sauf que ...
Posté par Gof (Jabber id, page perso, ) le 14/01/2009 à 12:38. (lien). Évalué à 4.En gros il peut faire un logiciel proprio et le vendre sans payer de licence, à condition:
- de fournir Le code source des modifications apporté dirrectement à Qt s'il y en a;
- de permettre à l'utilisateur d'utiliser son logiciel avec une version modifiée de Qt (i.e: pas de liaison statique)
[Gros résumé]
-
[^]Re: Sauf que ...
Posté par Benjamin Poulain (page perso, ) le 14/01/2009 à 12:44. (lien). Évalué à 4.C'est tout à fait ça, avant il y avait les licences GPL et proprio.
Avec la GPL, tu peux faire du libre, tu ne payes pas, mais ça doit rester GPL.
Avec la licence proprio, tu peux faire ce que tu veux, mais tu payes.
Avec la LGPL, tu ne peux pas faire ce que tu veux (le code de Qt doit rester libre), mais tu peux lier ton programme proprio à Qt sans payer.
Pourquoi est-ci si important d'éviter de payer une licence?
Premièrement pour les petits développeurs qui se lancent sans savoir si leur projet va réussir, ils pourront se lancer sans payer les frais d'entrées d'une licence.
Deuxièmement pour toutes les entreprises radines qui ferait tout pour payer moins (et ils y en a beaucoup). Eux j'espère que si ils profitent de Qt, ils auront la décence de publier aussi des binaires pour Linux, ce qui augmentera la force de l'écosystème.
Finalement, les entreprises qui ne veulent pas prendre trop de risques continueront à payer du support et à acheter des licences pour être sûr que leurs problèmes soient réglés rapidement.--
Visitez Linux Certif, le site qu'il est bien pour les Linuxiens. (Passez voir aussi OpenYourCode pour les développeurs)-
[^]Re: Sauf que ...
Posté par LeBouquetin () le 14/01/2009 à 13:43. (lien). Évalué à 4.Deuxièmement pour toutes les entreprises radines qui ferait tout pour payer moins (et ils y en a beaucoup). Eux j'espère que si ils profitent de Qt, ils auront la décence de publier aussi des binaires pour Linux, ce qui augmentera la force de l'écosystème.
Je présume que les boîtes radines ne changeront pas leur plateformes cible simplement parce que QT a changé de licence. Lorsqu'on vend une application et qu'on souhaite la distribuer sur différentes plateformes, il y a d'une part le développement qui doit être multi-plateforme, mais il y a aussi les installeurs, le support, etc. Et le développement, au final, c'est la partie visible de l'iceberg (je ne parle même pas de société radine, là, en fait).
Dans ma boîte, on développe des applis qui tournent sous linux et windows. On supporte Windows XP et la série des OS à base RedHat (RedHat, CentOS, Fedora, etc). Mais pas Mandriva par exemple. Ni Debian, ni Ubuntu, ni ... Pourtant ça compile et ça tourne sous Debian. C'est une question de packaging, de support. Quand un client a un problème, il faut le reproduire. On est une petite structure, donc on n'a pas toutes les plateformes/tous les OS à disposition, et/ou les compétences spécifiques à chaque OS/distribution.-
[^]Re: Sauf que ...
Posté par Benjamin Poulain (page perso, ) le 14/01/2009 à 14:10. (lien). Évalué à 1.Je me suis laissé emporté par mon optimisme :)
Ce que je vois maintenant, c'est des amis qui galère sur des trucs comme MFC ou Carbon+Cocoa. Leur boîte ne proposera jamais de solution en dehors de l'OS de départ parce qu'ils ont fait l'erreur de se bloquer sur une plateforme.
Si ils commencent sur la plateforme X avec Qt (puisque maintenant c'est gratuit), et qu'un client demande si ils peuvent l'utiliser sur la plateforme Y, ce sera du domaine du possible. Et j'espère que Y ce sera Linux :)
J'avoue que tout n'est pas aussi facile, il suffit de voir le nombre d'application Java qui ne fonctionnent que sur une seule plateforme...--
Visitez Linux Certif, le site qu'il est bien pour les Linuxiens. (Passez voir aussi OpenYourCode pour les développeurs)
-
-
-
rms ?
Qu'en pense RMS ? N'est-ce pas plutot une mauvaise nouvelle pour tous les purs à durs à poil long du Logiciel Libre ?
-
[^]Re: rms ?
Posté par GeneralZod () le 14/01/2009 à 12:20. (lien). Évalué à 4.Il doit s'en battre les roubignoles:
1. la licence GPL est conservée.
2. la licence LGPL reste une licence GNU.
3. même si la LGPL est moins appréciée que sa grande soeur la GPL, c'est considéré comme un mal nécessaire pour permettre l'interopérabilité entre le libre et le propriétaire.
4. RMS cherche à créer un écosystème libre auto-suffisant et utilisable par tous, et non pas à exterminer le logiciel propriétaire.-
[^]Re: rms ?
Posté par Kangs () le 14/01/2009 à 12:27. (lien). Évalué à 1.http://www.gnu.org/licenses/why-not-lgpl.fr.html
Pour une position claire de RMS sur la LGPL
-
[^]Re: rms ?
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 14/01/2009 à 15:46. (lien). Évalué à 4.5. RMS n'utilise que emacs en console, il n'a donc pas besoin de Qt. :)
-
[^]Re: rms ?
Posté par sanao () le 14/01/2009 à 16:37. (lien). Évalué à 3.Si c'est un mordu de la console, il pourrait même recoder Emacs avec juste QtCore. C'est y pas beau?!
-
[^]Re: rms ?
Posté par GeneralZod () le 14/01/2009 à 16:55. (lien). Évalué à 3.QtCore c'est du C++ et même pas du C++ standard, et RMS a décidé que GNU serait codé en C (avec un coding style tout pourri inspiré du Lisp) point barre.
-
[^]Re: rms ?
Posté par CrEv (page perso, ) le 14/01/2009 à 17:13. (lien). Évalué à 2.Allez, quelques exemples... [http://www.gnu.org/prep/standards/standards.html]
if (x < foo (y, z))
haha = bar[4] + 5;
else
{
while (z)
{
haha += foo (z, z);
z--;
}
return ++x + bar ();
}
static char *
concat (s1, s2) /* Name starts in column one here */
char *s1, *s2;
{ /* Open brace in column one here */
...
}
do
{
a = foo (a);
}
while (a > 0);
Et après ils vont se plaindre que GNU (hurd) n'avance pas et que personne veut coder dessus...-
[^]Re: rms ?
Posté par Nicolas Legrand () le 14/01/2009 à 17:41. (lien). Évalué à 2.Ho j'ai eu peur qu'ils veulent que le code du GNU soit en C K&R première édition, mais ça vient juste après « if you want to use traditional C syntax. »
C'est effectivement horrible. Vive la syntaxe du merveilleux practice of Programming (<http://cm.bell-labs.com/cm/cs/tpop/>), vive la syntaxe issue du fantastique 4.4BSD-lite2 (<http://www.openbsd.org/cgi-bin/man.cgi?query=style>).-
[^]Re: rms ?
Posté par baud123 (Jabber id, page perso, ) le 14/01/2009 à 19:23. (lien). Évalué à 4.et pour avoir des liens qui fonctionnent, tu peux les mettre entre crochets plutôt que < et > :
[http://cm.bell-labs.com/cm/cs/tpop/]
[http://www.openbsd.org/cgi-bin/man.cgi?query=style]
ce qui évite l'effet parenthèses ;-)
-
-
-
-
[^]Re: rms ?
Posté par Gof (Jabber id, page perso, ) le 14/01/2009 à 16:56. (lien). Évalué à 3.Un éditeur de texte en console fait avec QtCore...
mais ça existe déjà: http://www.yzis.org
Par contre c'est un clone de Vi, pas de emacs.
-
-
-
-
[^]Re: rms ?
arrêter de comparer les carottes aux poireaux !!
Un jour il faudra arrêter de comparer une bibliothèque sympa de graphique : GTK+ avec une bibliothèque multiplateforme complète de développement de logiciel, gérant nativement : le son, les vidéos, le svg, le tout en restant multiplateforme : Qt.
-
[^]Re: arrêter de comparer les carottes aux poireaux !!
Posté par GeneralZod () le 14/01/2009 à 13:07. (lien). Évalué à 8.La comparaison Gtk+/Qt est à la fois non pertinente et pertinente.
Non pertinente, parce que l'équivalent de Qt c'est GLib/Cairo/Gtk+/GStreamer/GtkWebKit/libxml2 etc ...
Pertinente, car si Qt est un framework unifié maintenue par une entité (Qt Software), on peut considérer que l'ensemble des bibliothèques autour de Gtk+ constituent un framework à part entière dont le ciment est GObject et qui offre (en pratique) également une vraie cohérence.
Moi, j'apprécie les 2 plateformes, la première pour son côté tout-en-un (framework extrêmement complet, outils associés performants), la seconde pour la possibilité de réutiliser séparément les différents composants, son dynamisme (D-Bus, Telepathy, GEGL, Gnome-Scan etc ...).
La différence principale c'est le modèle de développement, Qt est clairement une cathédrale (et une magnifique!), alors que Gtk+ & cie c'est le bazar. Chaque modèle à ses qualités et défauts, et Qt s'ouvre un peu plus au bazar.-
[^]Re: arrêter de comparer les carottes aux poireaux !!
Posté par rewind () le 14/01/2009 à 18:20. (lien). Évalué à 4.Il y a quelques approximations dans ce que tu dis.
Ni cairo, ni libxml2 ne sont basés sur GObject (<troll>et tant mieux</troll>).
Qt est très bien séparé en module et les modules sont tous indépendants.
-
[^]Re: arrêter de comparer les carottes aux poireaux !!
Posté par GeneralZod () le 14/01/2009 à 19:07. (lien). Évalué à 4.Certes, mais ils font quant même partie de la toolbox du développeur Gtk+, Gtk+ s'appuie principalement sur les primitives de dessins de Cairo (le GDK fournit des fonctions d'interopérabilité avec Cairo), et libxml2 c'est le parseur xml du projet GNOME. ;-)
Si il n'y a pas de wrappers GObject, c'est que d'une part, l'utilité ne s'est pas fait sentir, d'autre part pour des raisons de performances. Par exemple, GStreamer utilise en interne GstMiniObject (GObject moins les fonctionnalités inutiles pour GStreamer) et non GObject comme classe de base pour des raisons de performances.
> Qt est très bien séparé en module et les modules sont tous indépendants.
Seulement depuis Qt4, c'était beaucoup moins drôle avec Qt3.
Ce que je voulais dire, c'est qu'il est plus facile d'introduire dans un projet une bibliothèque GObject qu'une bibliothèque Qt même si c'est faisable.
-
-
-
[+] [^]Re: arrêter de comparer les carottes aux poireaux !!
Posté par chicha () le 14/01/2009 à 13:07. (lien). Évalué à -3.Je n'ai pas bien compris ce que tu voulais dire.
Tu peux être plus clarifié, stp ?-
[^]Re: arrêter de comparer les carottes aux poireaux !!
Posté par grid () le 14/01/2009 à 21:32. (lien). Évalué à 4.Pour reprendre une analogie de voiture. (qui est un max foireuse, tout le monde le sait)
GTK c'est une roue, Qt étant la voiture complète.-
[^]Re: arrêter de comparer les carottes aux poireaux !!
Posté par Vador Dark (Jabber id, ) le 16/01/2009 à 18:32. (lien). Évalué à 1.Oui mais Qt, c'est la voiture complète, pour le prix de la roue seule !
(Bon ok, elle était facile...)
-
-
Qt4 dans OpenOffice.org
Il y a une demande des utilisateurs qu'OpenOffice.org soit programmé en Qt4 mais c'était impossible car OOo est sous LGPL et Qt était uniquement sous GPL. Désormais, c'est possible. La communauté n'a plus qu'à se réfléchir à cela.
-
[^]Re: Qt4 dans OpenOffice.org
Posté par GeneralZod () le 14/01/2009 à 13:26. (lien). Évalué à 1.Je ne vois pas le problème la LGPL étant 100% compatible avec la GPL. Le seul truc serait qu'un port de la VCL (le toolkit d'OOo, à ne pas confondre avec le machin de Borland) vers Qt4 aurait été sous GPL (et là encore, je ne vois pas le problème).
Néanmoins, je vois pas vraiment l'intérêt de ce port, OOo est une usine à gaz, KOffice 2.0 (ainsi que la plupart des applications KDE4) est censé être multiplateforme et Qt 4.5 intégrera un support d'OpenDocument (Suffisant pour écrire un mini-traitement de texte sur plateforme mobile ;o) ). Quant à l'intégration visuelle, il y a le moteur de style gtk-qt ou on peut opter pour QGtkStyle.
Même en chargeant les libs KDE4, KOffice 2.0 reste moins lourdingue qu'OOo-
[^]Re: Qt4 dans OpenOffice.org
Posté par Benjamin Poulain (page perso, ) le 14/01/2009 à 13:39. (lien). Évalué à 4.Même si je suis d'accord qu'un suite office directement en Qt serait bien mieux, il n'en reste pas moins qu'avoir OOo en Qt serait génial.
OOo est une usine à gaz, mais il est bien répandu et il a plus de fonctionnalité que KOffice 2. Utiliser Qt pour OOo aurait du sens selon moi.--
Visitez Linux Certif, le site qu'il est bien pour les Linuxiens. (Passez voir aussi OpenYourCode pour les développeurs)
-
[^]Re: Qt4 dans OpenOffice.org
Posté par Frédéric COIFFIER () le 14/01/2009 à 13:41. (lien). Évalué à 1.Sun voulait peut-être pouvoir continuer à vendre StarOffice sans avoir à en donner le code source ?
-
[^]Re: Qt4 dans OpenOffice.org
Posté par sanao () le 14/01/2009 à 13:52. (lien). Évalué à 4.Maintenant ils peuvent faire cela.
Maintenant niveau travail. Un portage vers Qt est énorme et donc long, mais cela peut offrir nombres d'avantages comme faire du nettoyage dans le "bouzin" (dixit les nombreux commentaires sur le code) et très certainement le rendre plus réactif.-
[^]Re: Qt4 dans OpenOffice.org
-
[^]Re: Qt4 dans OpenOffice.org
Posté par Claude Computing () le 14/01/2009 à 17:09. (lien). Évalué à 2.Il me semblait qu'un certain nombre de composant d'OO étaient ou devaient être en Java, qu'en est-il ?
Au fait Qt Jambi va t'il lui aussi être distribué sous LGPL ?
Ca va peut-être booster son adoption sur Java face à l'ugly SWT et au heavy Swing
-
-
-
-
[^]Re: Qt4 dans OpenOffice.org, et FireFox ?
Posté par nicolap () le 14/01/2009 à 14:32. (lien). Évalué à 2.Firefox et Thunderbird qt pour une meilleure intégration dans kde ça serait génial aussi :)
Il semble que Nokia travaille dessus mais ce n'est pas intégré à ce jour dans les distro principales.
http://www.paperblog.fr/973155/mozilla-firefox-3-porte-sous-(...)
-
[^]Re: Qt4 dans OpenOffice.org
Posté par Eric Bachard (page perso, ) le 16/01/2009 à 21:19. (lien). Évalué à 6.Bonjour,
Ayant moi-même beaucoup contribué au port natif Mac OS X (aka Aqua), je connais bien vcl ( voir les liens plus bas), et ayant découvert aujourd'hui seulement l'éxistence du passage à la LGPL de Qt, grâce à Eric Bischoff (cf mon blog : http://eric.bachard.free.fr/news ), je pense que ce n'est pas si simple :
1) pour les widegets : ok, ca doit marcher, et c'est portable. Tout le monde est d'accord avec ça.
2) pour les polices et les devices virtuels, et plein d'autres choses qui sont utilisées par tout OpenOffice.org, c'est déjà moins clair
3) l'interaction avec svx et sfx2 est pour le moins problèmatique
4) enfin, comme l'a bien mis en évidence Malte Timmermann, qui gère l'accessibilité (une grande force de la version 3.0 sous Mac OS X ! ), dans le mail que j'indique sur mon billet de blog, et bien là, c'est pas sûr du tout : la faisabilité dépend a priori du port concerné.
Dans tous les cas, c'est un boulot monstre qui attend les dévs d'OpenOffice.org, qui ne sont pas si nombreux, enfin, vous voyez ce que je veux dire ...
Désolé d'avoir modéré l'enthousiasme de certains, mais à part un gros changement, je ne vois pas ça dans un futur proche pour OpenOffice.org
Une vieille documentation sur vcl, sans code :
http://wiki.services.openoffice.org/wiki/User:Ericb#Sort_of_(...)
Note: SalOpenGL et SalSound sont obsolètes aujourd'hui, et pour OpenGL (surtout pour Impress), on fait autrement .
Une documentation assez vieille, mais faite avec Doxygen (attention, décompressé, c'est assez énorme :
http://eric.bachard.free.fr/mac/aquavcl/documentation/doc_06(...)
Me demander pour quelque chose de plus récent--
qɔᴉɹə
Education Project: http://wiki.services.openoffice.org/wiki/Education_Project
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.free.fr/news
Et on est pas le 1er avril !
J'ai hâte d'être dans un an ou deux pour voir ce que cela va donner : j'espere qu'il y aura un bon "écosystème", plus de développeurs, plus de librairies tierces, plus de logiciels multiplateformes.
En tout cas ils veulent créer une vrai communauté cf FAQ : pourrais je contribuer à Qt ? Oui, absolument. Nous travaillons sur les détails finaux de notre modèle de contribution
Il est prevu que Qt-4.5 sorte en mars cf FAQ
D'après http://labs.trolltech.com/blogs/2009/01/14/nokia-to-license-(...)
Nous continuerons d'évaluer l'adoption, l'utilisation et l'interprétation légale de la LGPLv3 par la communauté et
peut être utiliser la LGPLv3 pour les prochaines releases
Pendant un quart de seconde j'ai pensé qu'on était un 1er avril :D
Finalement c'est une bonne chose que Nokia est racheté Trolltech !
-
[^]Re: Et on est pas le 1er avril !
Posté par baud123 (Jabber id, page perso, ) le 14/01/2009 à 17:42. (lien). Évalué à 2.Pendant un quart de seconde j'ai pensé qu'on était un 1er avril :D
ils auraient ajouté qu'ils regardaient la transition du C++ à Java dans ce cas alors ;-)
[+] S'ils avaient voulu il y a wxWidgets qui est en LGPL
S'ils avaient voulu tout aurait pu être codé en utilisant wxWidgets et qui n'est pas si mal que ça même comparé à Qt. Donc pourquoi ils changeraient maintenant...
-
[^]Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL
Posté par sanao () le 14/01/2009 à 18:03. (lien). Évalué à 5.A côté des fonctionnalités de Qt, wxWidgets fait très primaire. Sans oublier la documentation qui est une des grandes forces de Qt.
Concernant la qualité de l'API de wxWidgets (que je n'ai pas utilisé), j'ai lu à plusieurs reprise qu'ils avaient voulu trop copier les MFC et qu'au final la qualité n'était pas souvent au rendez-vous.
En résumé, Qt est sur bien des points très en avance sur tous ses concurrents.-
[^]Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL
Posté par Claude Computing () le 14/01/2009 à 18:39. (lien). Évalué à 6.En particulier un des reproches fait à wxWidgets est son mécanisme de callback qui s'apparente aux MFC en face du mécanisme de signaux/slot de Qt.
Le leader du toolkit FOX en parle mieux que moi
http://www.fox-toolkit.org/faq.html#CALLBACKS
Il y a aussi le fait que wxWidget s'appuie(yait) pas mal sur les toolkits natifs au lieu de s'appuyer que sur un noyau de primitives graphiques portées pour chaque plateforme.
Ceci a l'inconvénient d'avoir un aspect et un comportement moins homogène pour les widgets réutilisés et pas réécrits. Et la création d'un nouveau widget pas commun à plusieurs plateformes nécessite une réécriture pour chaque plateforme au lieu de s'appuyer sur les primitives de base.
Je crois que ca a changé avec les dernières versions mais ces erreurs de jeunesse pèsent et laissent une impression d'API héteroclite-
[^]Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL
Posté par Zenitram (page perso, ) le 14/01/2009 à 19:18. (lien). Évalué à 2.Il y a aussi le fait que wxWidget s'appuie(yait) pas mal sur les toolkits natifs au lieu de s'appuyer que sur un noyau de primitives graphiques portées pour chaque plateforme.
Ceci a l'inconvénient d'avoir un aspect et un comportement moins homogène pour les widgets réutilisés et pas réécrits.
Tiens, c'est justement ce qui me plait chez WxWidgets: l'application semble plus "native" que sous Qt (qui est déja bien, mais moins "native" parfois)
Comme quoi, les goûts et les couleurs ;-)
Mais effectivement, en pratique, ça amène quelques galères, comme la limitation au plus petit commun dénominateur graphique (ça plus le manque dévolution comparé à Qt... A force, je vais basculer, j'y passerai bientôt!)-
[^]Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL
Posté par Gof (Jabber id, page perso, ) le 14/01/2009 à 19:35. (lien). Évalué à 6.Pour mon information, aurais tu un exemple de chose qui parait plus « native » avec WxWidgets que avec Qt ?
-
[^]Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL
Posté par Zenitram (page perso, ) le 14/01/2009 à 21:43. (lien). Évalué à 6.Pour un exemple basique de chez basique, sous Windows (sans prendre les nouvelles barre à la Office, encore différentes, le Toolkit Windows évoluant aussi):
- Une application "native" ou Wx aura le menu ouvert (Ouvrir, Fermer...) avec une couleur légèrement différente de la barre de menu. Sous Qt, même couleur.
- Quand on passe la souris sur un menu avec une icône, une application aura le fond du texte en bleu, le fond de l'icône en gris. Sous Qt, l'ensemble (Texte + icône) a un fond bleu.
J'ai pris vite fait ces exemples sur VLC pour Qt, il y en a plein comme ça.
C'est du détail, vraiment du détail, mais c'est ce qui fait qu'un utilisateur se sens "chez lui".
Et je re-précise : c'est du détail. Car comparé à GTK, on est sauvé (un windowsien touchant à une appli GTK qui n'a pas pris la peine de changer la boite "Ouvrir un fichier" et de changer le thème par défaut va s'enfuir en courant au bout de 30s à cause l'interface horriblement non intégrée et du menu "Ouvrir"...), une interface Qt n'est pas si dérangeante que ça et je me motive depuis quelque temps pour mettre mon passage à Qt dans le haut de ma ToDo list.
-
-
-
-
[+] Youhouu !
Chouette, on va peut-être enfin voir la fin de GTK. Et surtout de ses prosélytistes à la con qui se croient obligés d'y faire référence alors que la dépèche ne concerne que QT.
-
[^]Re: Youhouu !
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 15/01/2009 à 09:34. (lien). Évalué à 3.Et peut être même qu'un jour on verra la fin des commentaire de personnes qui se sentent obligé de parler de GTK dans les news de Qt juste pour cracher sur les personnes qui apprécient le premier.
L'espoir fait vivre.
-
[^]Re: Youhouu !
Posté par windu.2b (Jabber id, page perso, ) le 15/01/2009 à 09:48. (lien). Évalué à 6.Et pour ceux qui parlent de QT (c'est à dire QuickTime) dans une dépêche sur Qt, on fait quoi ?
-
[+] [^]Re: Youhouu !
Posté par nainportequoi () le 15/01/2009 à 23:38. (lien). Évalué à -1.Oh, un tétracapilectomiste ! :) Bonjour ! :)
-
Qt == killer app ?
Et si finalement Qt était la killer app [1] tant attendue ? celle qui permettrait à Linux d'être crédible et de percer enfin (cad de mon point de vue atteindre entre 5 et 10% de PDM)
On a longtemps cru que ce serait une application classique genre Amarok, Gimp ou Apache, pourquoi pas une librairie ou un langage (PHP par ex) ?
Pour reprendre un commentaire sur Slashdot :
having used GTK, wxWidgets, XForms, V, Motif, MFC, Borland VCL, Visual Basic, Swing, AWT, GNUStep and Qt, I have to say that Qt beats the others [2]
On a donc :
- un toolkit bien meilleur que les autres
- gratuit et libre pour tous
- des supers outils (Qt Creator, Qt Designer)
- disponible partout même sur les téléphones
- supporte plein de langages (C++, Java, Python...)
- et surtout financé par Nokia qui a les moyens de ces ambitions : "Qt Everywhere"
Et je pense que Nokia a beaucoup d'ambitions pour Qt : LGPL, recrutement de développeurs, portage sur pleins de nouvelles plateformes...
On peut toujours rêver mais l'idée me plait :-)
Et la cerise sur le gâteau : un Windows 7 pire que Vista :p
[1] http://fr.wikipedia.org/wiki/Killer_app
[2] http://tech.slashdot.org/comments.pl?sid=1091547&cid=264(...)
-
[^]Re: Qt == killer app ?



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.