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. Ce changement de licence de Qt s'accompagne également d'une ouverture supplémentaire du développement de Qt : désormais, le code source de Qt sera disponible dans un dépôt Git, permettant de suivre plus aisément son développement. Ce changement a été réalisé dans le cadre de l'initiative "Qt Everywhere" : Qt Software s'engage à retirer tout ce qui peut s'opposer à l'utilisation de Qt, quand c'est réalisable. Cela inclut donc les problèmes de licence. Il ne s'agit pas d'un abandon de Qt par Nokia, bien au contraire : Nokia peut se passer des revenus des licences commerciales de Qt, ce que Trolltech ne pouvait pas se permettre.
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.
»
Aller plus loin
- Rachat de Trolltech par Nokia sur DLFP (4 clics)
- Annonce officielle (3 clics)
- Ars Technica : Nokia Qt LGPL switch huge win for cross-platform development (4 clics)
- Qt Labs Blog : Sebastian Nyström Qt KDE News Nokia to license Qt under LGPL (4 clics)
- DLFP : Nokia rachète Trolltech (1 clic)
- DLFP : Nokia rachète Symbian (1 clic)
# Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par Benjamin Poulain (site web personnel) . Évalué à 10.
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
[^] # Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par vida18 . Évalué à 3.
[^] # Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par Zenitram (site web personnel) . Évalué à 3.
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 . Évalué à 3.
[^] # Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par HoloAddict (site web personnel) . Évalué à 2.
[^] # Re: Qt passe en LGPL et adopte un modèle de dévelopement ouvert
Posté par Zenitram (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
# Ha zut...
Posté par Arnaud . Évalué à 8.
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 . Évalué à 4.
"Gnome ça pue y a qu'un bouton, KDE ça roxxxe y a plein d'options partout !"
[^] # Re: Ha zut...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Ha zut...
Posté par Larry Cow . Évalué à 3.
[^] # Re: Ha zut...
Posté par lmg HS (site web personnel) . Évalué à 2.
[^] # Re: Ha zut...
Posté par sanao . Évalué à 2.
Comment ça j'ai marché dedans!
[^] # Re: Ha zut...
Posté par syj . Évalué à 2.
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 . Évalué à 3.
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 Bozo_le_clown . Évalué à 4.
[^] # Re: Ha zut...
Posté par vincent_k (site web personnel) . Évalué à 2.
[^] # Re: Ha zut...
Posté par sanao . Évalué à 2.
On est arrivé au bout je crois.
[^] # Re: Ha zut...
Posté par nooky59 . Évalué à 5.
# Version
Posté par 2PetitsVerres . Évalué à 3.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Version
Posté par Pinaraf . Évalué à 3.
# Sauf que ...
Posté par Jérôme . Évalué à 2.
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 . Évalué à 3.
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 David Bonnin . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Sauf que ...
Posté par Jérôme . Évalué à 3.
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 BAud (site web personnel) . Évalué à 2.
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 ...
Posté par Jérôme . Évalué à 1.
[^] # Re: Sauf que ...
Posté par David Bonnin . Évalué à 1.
Est-ce aussi LGPL?
[^] # Re: Sauf que ...
Posté par Philippe F (site web personnel) . Évalué à 1.
[^] # Re: Sauf que ...
Posté par David Bonnin . Évalué à 2.
En RAM, ROM, puissance?
[^] # Java par définition s'est Open Source
Posté par syj . Évalué à 1.
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 psychoslave__ (site web personnel) . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 5.
Ça s'appelle un pisseur de code
[^] # Re: Java par définition s'est Open Source
Posté par psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: Java par définition s'est Open Source
Posté par CrEv (site web personnel) . Évalué à 5.
je croyais que c'était intégré en standard...
[^] # Re: Sauf que ...
Posté par David Bonnin . Évalué à 1.
[^] # Re: Sauf que ...
Posté par Florimond . Évalué à 1.
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 (site web personnel) . Évalué à 4.
- 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 (site web personnel) . Évalué à 4.
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.
[^] # Re: Sauf que ...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
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.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Sauf que ...
Posté par Benjamin Poulain (site web personnel) . Évalué à 1.
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...
# rms ?
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: rms ?
Posté par GeneralZod . Évalué à 4.
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 . Évalué à 1.
Pour une position claire de RMS sur la LGPL
[^] # Re: rms ?
Posté par psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: rms ?
Posté par sanao . Évalué à 3.
[^] # Re: rms ?
Posté par GeneralZod . Évalué à 3.
[^] # Re: rms ?
Posté par CrEv (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 BAud (site web personnel) . Évalué à 4.
[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 (site web personnel) . Évalué à 3.
mais ça existe déjà: http://www.yzis.org
Par contre c'est un clone de Vi, pas de emacs.
[^] # Re: rms ?
Posté par Kangs . Évalué à 2.
J'attends avec impatience sa réaction.
# arrêter de comparer les carottes aux poireaux !!
Posté par djibb (site web personnel) . Évalué à 10.
[^] # Re: arrêter de comparer les carottes aux poireaux !!
Posté par GeneralZod . Évalué à 8.
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 (Mastodon) . Évalué à 4.
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 . Évalué à 4.
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 Ririsoft . Évalué à -3.
Tu peux être plus clarifié, stp ?
[^] # Re: arrêter de comparer les carottes aux poireaux !!
Posté par grid . Évalué à 4.
GTK c'est une roue, Qt étant la voiture complète.
[^] # Re: arrêter de comparer les carottes aux poireaux !!
Posté par Vador Dark (site web personnel) . Évalué à 1.
(Bon ok, elle était facile...)
# Qt4 dans OpenOffice.org
Posté par vida18 . Évalué à 9.
[^] # Re: Qt4 dans OpenOffice.org
Posté par GeneralZod . Évalué à 1.
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 (site web personnel) . Évalué à 4.
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.
[^] # Re: Qt4 dans OpenOffice.org
Posté par Frédéric COIFFIER . Évalué à 1.
[^] # Re: Qt4 dans OpenOffice.org
Posté par sanao . Évalué à 4.
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
Posté par vida18 . Évalué à 1.
[^] # Re: Qt4 dans OpenOffice.org
Posté par Bozo_le_clown . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 6.
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
# Et on est pas le 1er avril !
Posté par tanguy_k (site web personnel) . Évalué à 2.
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 BAud (site web personnel) . Évalué à 2.
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
Posté par cppuser . Évalué à -1.
[^] # Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL
Posté par sanao . Évalué à 5.
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 Bozo_le_clown . Évalué à 6.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 6.
[^] # Re: S'ils avaient voulu il y a wxWidgets qui est en LGPL
Posté par Zenitram (site web personnel) . Évalué à 6.
- 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 !
Posté par nainportequoi . Évalué à -2.
[^] # Re: Youhouu !
Posté par psychoslave__ (site web personnel) . Évalué à 3.
L'espoir fait vivre.
[^] # Re: Youhouu !
Posté par windu.2b . Évalué à 6.
[^] # Re: Youhouu !
Posté par nainportequoi . Évalué à -1.
# Qt == killer app ?
Posté par tanguy_k (site web personnel) . Évalué à 10.
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 ?
Posté par dkremer . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.