Il s'agit d'une "boite à outils" (toolkit) pour faciliter le travail des programmeurs en leur proposant une multitude de routines qui assurent la cohérence des logiciels développés.
Ainsi l'environnement de bureau KDE est basé sur Qt et l'environnement de bureau Gnome est basé sur Gtk+.
Qt est actuellement en version 3.3 et Trolltech qui est l'entreprise derrière cette boite à outils annonce la disponibilité de la prochaine grande version (version 4.0) dans la seconde moitié de cette année. Les principales nouveautés : -Arthur : nouveau "paint engine" qui gère parfaitement le bitmap et le vectoriel ainsi que PostScript, SVG, et OpenGL
-Scribe : nouveau "text-rendering engine" qui gère parfaitement l'unicode et est conçu pour le multilinguisme.
-Tulip : un nouvel ensemble de "containers" plus rapides.
-Intégration entre Qt Designer et Qt Assistant.
-Support intensif du multithreading.
-Nouvelle architecture de "docking".
-Accessibilité multiplateforme pour les handicapés radicalement améliorée.
-Rapidité accrue et empreinte mémoire réduite.
Beaucoup d'autres nouveautés sont listées sur la page d'annonce de Trolltech.
Aller plus loin
- L'article sur Qt4 (5 clics)
- Le "Qt Quarterly" de ce trimestre (4 clics)
# Re: Qt 4 à l'horizon !
Posté par fouinto . Évalué à 2.
Je ne voudrais pas relancer un troll... mais il me semble que seule une vieille version (version 2 QQ chose) est libre pour windows non? il me semble par contre qu'il existe une version libre pour linux (GPL)
je sais qu'on est sur linuxfr.org :) mais, quand on développe une interface graphique susceptible d'être un jour portée sous windows... on est en droit de se poser des questions...
Sinon, mon impression perso, étant amateur de programmation en C++, Qt 3 est VRAIMENT très bien :) alors vivement cette version 4 :)
[^] # Re: Qt 4 à l'horizon !
Posté par Infernal Quack (site web personnel) . Évalué à 3.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Qt 4 à l'horizon !
Posté par BiBite . Évalué à 1.
Et pour aller plus loin, en admettant que ce soit posible, est-ce que j'ai le droit de distribuer mon application avec les librairies Qt propriétaires (sous forme binaire donc) ?
[^] # Re: Qt 4 à l'horizon !
Posté par Sylvain (site web personnel) . Évalué à 1.
http://psi.affinix.com/(...)
[^] # Re: Qt 4 à l'horizon !
Posté par Piksou . Évalué à 2.
Tu peux distribuer ton prog sous une GPL qui contienne une clause d'exception
La GPL pure impose de n'être lié qu'à du (compatible) GPL
donc tu dois rajotuer une ligne autorisant à lier à QT 4 non-GPL
Ton prog aura dès lors le mêm comportement qu'un prog GPL (obligation de fournir les sources, etc.) et son code sera compatible GPL MAIS tu NE pourra PAS prendre de code GPL à un autre projet GPL ni te lier à une lib GPL.
[^] # Re: Qt 4 à l'horizon !
Posté par reno . Évalué à 0.
Si je me rappelle bien il y avait un débat sur cette 'clause d'exception' du temps ou Qt n'était pas GPL sur Linux et les developpeurs de KDE ne pensaient pas que cette clause d'exception était nécéssaire.
Je suis plutot de leur avis: je ne vois pas quelle clause de la GPL impose ce que tu dis..
Que je sache il existe des tas de soft GPL pour Windows, ils ont tous cette exception?
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 1.
Perso, je connais pas beaucoup de softs GPL pour Windows utilisant QT...
[^] # Re: Qt 4 à l'horizon !
Posté par Piksou . Évalué à 2.
For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
à l'époque de KDE, la team KDE disant en substance "vu que notre soft est pour QT, il et évident que l'on autorise à lier à QT", ce qui était très discutable et d'ailleurs rejeté par Debain qu il'avait exclus estimant avec raison que QT n'avait rien de fondamental dans le système et surtout que distribuer les deux ensemble était pile dans l'exclusion qui suit le unless. en revanche, ils considéraient que l'on pouvait installer KDE depuis les sources, dans ce cas les deux n'étant pas liés, on pouvait en tirant les cheveux considérer QT comme faisant partie du système. sous windows, un tel procédé n'est pas possible.
clause d'exception ou double licence; dans les deux cas tu ne peux pas "récupérer" de code GPL dans d'autres projets.
[^] # Re: Qt 4 à l'horizon !
Posté par peau chat . Évalué à 3.
GPL pour ceux qui vont l'exécuter avec une QT GPL.
Non-GPL pour ceux qui veulent l'exécuter en Windows natif.
[^] # Re: Qt 4 à l'horizon !
Posté par VACHOR (site web personnel) . Évalué à 1.
--> voir ici : http://doc.trolltech.com/qq/qq09-qt4.html(...)
(Qt is positioned as a superior alternative to Java, and as a multiplatform alternative to platform-specific APIs ...)
[^] # Re: Qt 4 à l'horizon !
Posté par drchaos (site web personnel) . Évalué à 1.
Ou peut on trouvé les sources de Qt en cours de développement ? ( un cvs par exemple).
[^] # Re: Qt 4 à l'horizon !
Posté par Staz . Évalué à 1.
par contre je sais pas si les sources de QT4 sont dispo
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . Évalué à 5.
[^] # Re: Qt 4 à l'horizon !
Posté par peau chat . Évalué à 2.
Pfff... c'est pourtant pas difficile à comprendre.
Depuis la V2, QT pour X-Window est en GPL. Je dis bien « pour X-Window»
Donc pour Linux, n'importe quel Unix, mais aussi pour Windows, ou bien MacOS sur lesquels tu fais tourner un serveur X11.
Depuis peu, la version « native » (c'est à dire directement, sans faire tourner X11 ) pour MacOS-X est également passée GPL.
Par contre, la version native Windows est uniquement en licence propriétaire.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe MAES (site web personnel) . Évalué à 0.
Et je crois meme que Trolltech ne peut pas mettre la version windows en GPL car ils utilisent une dll non libre copyright MS, qui ne fait pas partie du systeme.
Mais peut-etre un v4.0 sans cette dll ?
[^] # Re: Qt 4 à l'horizon !
Posté par Piksou . Évalué à 1.
tu sors ça d'ou ?
les vrais raisons ont déja été données lors du dernier topic sur trolltech: en substance ils ont peur que les boites violent la GPL et fassent du proprio avec la GPL
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par Piksou . Évalué à 3.
La DLL qui gère les thème doit bien être fournie donc elle relève de l'exception "anything that is normally distributed [...] with the major components [...] of the operating system" non ?
# Re: Qt 4 à l'horizon !
Posté par drchaos (site web personnel) . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par un_brice (site web personnel) . Évalué à 3.
[^] # Re: Qt 4 à l'horizon !
Posté par Epsos . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par un_brice (site web personnel) . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par Alexandre . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par un_brice (site web personnel) . Évalué à 1.
On n'est pas encore ensemble que je sache... on se rencontreras qu'en 2008.
Quoi que... j'suis plus sûr de rien.
# Re: Qt 4 à l'horizon !
Posté par Troy McClure (site web personnel) . Évalué à 1.
est bien sympathique aussi, c'est vraiment dommage que le c++ (standard) ne permette pas de faire ça.
Dans les commentaires de slashdot, j'avais quand même reperé un lien vers http://www.nwcpp.org/Meetings/2004/01.html(...) qui a l'air de décrire un moyen de faire le foreach sans passer par typeof (avec de grosses gruikeries sur les templates).
[^] # Re: Qt 4 à l'horizon !
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
Tu voulais dire le C standard non ?
Parce que dans le C++ standard, il me semble que l'on peut réaliser l'exemple que tu donnes.
[^] # Re: Qt 4 à l'horizon !
Posté par Epsos . Évalué à 1.
Dans la stl, le header definit une methode for_each(), template, permettant de rappeller un callback sur tous les elements entre deux itérateurs ...
Mais ca n'a pas vraiment beaucoup de chose a voir.
[^] # Re: Qt 4 à l'horizon !
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par shbrol . Évalué à 2.
Pour faire ce genre de chose, sans macros et avec une bibliotheque bien codee, il y a Boost.Lamba (http://www.boost.org/libs/lambda/doc/(...) ), et l'exemple que tu donnes s'écrirait:
ou encore, avec std::accumulate :
on peut trouver ca gruik, mais c'est beaucoup plus robuste.
(si la solution Qt n'est pas a base de macro, je n'ai rien dit, j'admire et je sors...)
[^] # Re: Qt 4 à l'horizon !
Posté par shbrol . Évalué à 2.
La macro foreach de Qt se nomme en fait Q_FOREACH, en majuscule pour bien montrer que c'est une macro, et avec un prefixe pour (essayer) d'éviter les collisions. Il est malheureusement possible en activant un flag de définir le synonyme "foreach", avec les conséquences qui en découlent.
L'auteur de l'article http://www.nwcpp.org/Meetings/2004/01.html(...) s'appelle Eric Niebler, et c'est un contributeur au projet Boost. Suite a la publicité récente sur le foreach de Qt, il vient de proposer sur la mailing list boost-devel une implementation de sa technique (et la macro se nommera BOOST_FOREACH, comme il se doit).
<ma vie>
il n'empeche que Boost.Lambda est beaucoup plus interessant.
</ma vie>
[^] # Re: Qt 4 à l'horizon !
Posté par Troy McClure (site web personnel) . Évalué à 1.
Sinon en termes de lisibilité (et de simplicité) je préfere quand même un foreach, même si c'est une sale macro :)
# Re: Qt 4 à l'horizon !
Posté par el_mickey . Évalué à 1.
PS: je sais il existe qtgtk mais je meme demande si il n'y aurait pas plus propre. qt et gtk ne pourraient pas s'entendre sur ce point ?
[^] # Re: Qt 4 à l'horizon !
Posté par Elrik de Melnibone . Évalué à 1.
Quand est ce que KDE passe à gconf ?
Qu'on peut renommer freedesktop-conf si ils veulent, et qui permettrait de partager tous les fichiers de conf et donc les themes. Reste ensuite à faire des themes avec les meme noms ou un truc du genre.
[^] # Re: Qt 4 à l'horizon !
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Tu as l'air motivé :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Qt 4 à l'horizon !
Posté par - - . Évalué à 6.
kde et gnome peuvent partager beaucoup de l'infrastructure, gconf n'oblige pas à utiliser gtk. il n'y a donc pas de risque pour kde de se "gnomiser"
quand à "look commun" cela n'est qu'un fantasme
kde et gnome ont par quasi _nature_ un "feeling" DIFFERENT
vous n'unifierez _pas_ les boites de dialogues, vous n'unifirez _pas_ les menus (nomemclature, etc) , vous n'unifierez _pas_ les réglages communs etc etc etc par un simple "look".
faudrait cesser donc de fantasmer tout haut, et accepter gnome et kde comme 2 plateformes de développements et graphiques différentes, avec leur force et défauts mais toutes les 2 libres.
rien ne vous empèche de vous focaliser sur l'un des 2 et de continuer à profiter d'un logiciel de l'autre environnement s'il est de qualité.
la situation n'est vraiment génante que pour les ISV et autres editeurs commerciaux qui ne peuvent se permettre de gérer 2 plateformes de développements. Pour le monde commercial, l'habituel sélection naturelle prévaudra (le plus adapté aux besoins gagnera).
Pour ce que je pense, les 2 sont viables et peuvent continuer à etre amélioré avec chacun une base d'utilisateurs dédiés)
[^] # Re: Qt 4 à l'horizon !
Posté par Éric (site web personnel) . Évalué à 1.
> (nomemclature, etc) , vous n'unifierez _pas_ les réglages communs etc etc etc
> par un simple "look".
Est-ce une raison pour ne pas uniformiser ce qu'on peut ?
Ma distrib propose par défaut un thème gtk et qt très proche. Je peux probablement faire la différence entre du gtk et du qt, mais le fait que ça soit proche visuellement (oui, je ne parle là que du graphisme) est un élément de confort important.
Il suffit de faire comme ça : deux thèmes proches, un en qt et un en gtk (bon, à vrai dire deux en gtk), mais ça demande beaucoup de boulot. Une uniformisation de certains paramètres serait bienvenue (au moins la couleur de fond par exemple).
Il ne s'agit pas de remplacer l'un par l'autre ou de les fusionner, mais de pouvoir utiliser une appli gtk et une qt sans rompre à ce point l'identité visuelle.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par calandoa . Évalué à -2.
Un malheureux exemple (assez extrême, tout de même) a été la suppression du réglage des raccourcis clavier sous gtk par défaut (on tape le raccourci avec le pointeur sur le menu) pour le faire ressembler à KDE! Il est toujours possible de le faire à condition d'aller bidouiller les fichiers de conf, mais j'ai trouvé ça un peu ridicule...
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 2.
C'est la première fois que j'entends ça comme raison pour la "suppression" de cette fonctionnalité.
Une certaine uniformisation entre les environnements est intéressante pour les gens qui utilisent à la fois des applis gtk/gnome et qt/kde. Les gens veulent utiliser une appli qui marche et avoir des applis qui ont l'air cohérentes les unes avec les autres, ils s'en foutent que X et Y soient complètement différents parce que un utilise kde et l'autre gnome.
[^] # Re: Qt 4 à l'horizon !
Posté par Erwan . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . Évalué à 4.
Pour resume, c'est difficile d'avancer parce que les deux solutions sont toutes les deux techniquement valables et en changer aurait d'une part des gros impacts en architectures, d'autre part un gros impact sur le bureau qui changerait.
La semaine derniere, un mec a propose sur la liste freedesktop un autre systeme de configuration global. Ce qui est ressorti de la facon dont il s'est fait allume, c'est que kconfig et gconf sont tous les deux des solutions bien eprouvees techniquement, qu'on ne peut pas remplacer facilement.
Les developpeurs ont bien la volonte de faire un systeme de configuration commun, pour partager des choses comme la bases de donnees mime, des themes, la configuration d'applications communes mais la solution technique n'a pas encore ete trouvee.
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 2.
Ca va ressembler à du troll de bas étage, mais dans ma tête gconf est plus puissant que kconfig (j'avoue que j'ai jamais regardé kconfig, donc mon avis vaut pas grand chose ;). Est-ce que kconfig permet de demander à ce qu'un callback soit invoqué lorsqu'une pref est modifiée (par l'appli elle même ou bien par toute autre appli) ? Est-ce que kconfig permet de "verrouiller" certaines options de config afin d'empêcher l'utilisateur de les modifier ?
[^] # Re: Qt 4 à l'horizon !
Posté par Prosper . Évalué à 2.
Je connais pas kconfig , mais j imagine que oui , parce qu avec kiosk ca sert justement a ca .
http://www.kde.org/areas/sysadmin/(...)
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . Évalué à 1.
Il fait la fusion entre un fichier de conf global et un fichier de conf local
Lors d'une modif, il ne va enregistrer la modif que si elle differe de la config par defaut.
Il s'appuie sur le filesystem pour stocker les fichiers de config. Le demon ksycoca utilise libfam (file access monitoring) pour noter les changements et les notifie via dcop.
Comme il s'appuie sur le systeme de fichier, c'est relativement simple de centraliser une config sur un serveur: tu montes un repertoire KDE par nfs.
Apres, pour les autres possibilites de gconf, je pense pas que kconfig fasse. Le xml est une tres mauvaise idee car les fichiers de conf doivent etre lus tres tres vite, ce qui est incompatible avec le parsage de xml.
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 1.
nfs+fam ça fonctionne pas je crois, donc t'as plus de notification dans ce cas là (accessoirement, je trouve ça un peu bancal de s'appuyer sur fam pour faire ça)
> Le xml est une tres mauvaise idee car les fichiers de conf doivent etre lus tres tres vite, ce qui est incompatible avec le parsage de xml.
Mouais... Comparé au temps d'accés à ton fichier de conf, le parsing xml est probablement pas très couteux. Et tu lis pas tes fichiers de conf 15000 fois par seconde non plus.
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
"Famous last words". Pour un fichier de config tu vas très probablement vouloir parser ça en DOM plutôt qu'en SAX, et ça c'est pas gratuit du tout. Ou alors tu vas te faire chier a coder un parser SAX qui ne sera pas beaucoup plus simple qu'un parser pour un format custom, et forcément moins rapide.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . Évalué à 1.
> est probablement pas très couteux.
Chaque microseconde compte parce que beaucoup de fichiers sont lu avant qu'une application puisse se lancer. Typiquement, tu lances KDE:
- dcop lit son fichier de conf
- sycoca lit son fichier de conf
- kwin lit son fichier de conf
Ensuite, tu lances konqueror:
- il lit tout son fichier de conf et l'interpret
- il charge khtml qui va faire de meme
En faisant des optimisations simples sur les fichiers de conf (le charger tout d'un coup, ne faire la conversion unicode qu'au dernier moment, n'interpreter que la cle qu'on recherche, ...), KDE avait divise par 5 le temps subjectif de chargement d'une application (temps subjectif au sens ou c'est le temps ou l'utilisateur a l'impression qu'il se passe qqch). Pourtant, c'etait avec un format hyper-simple style .ini
Avec un fichier xml, le temps de chargement est necessairement plus long et les applications en patissent.
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 1.
Temps d'accés à un fichier : 5 à 10 ms dans le meilleur des cas
Parsing d'un fichier xml de qques kilooctets : inférieur à la ms (enfin sauf si on utilise le parser xml de QT)
Si vous voulez vous plaindre que GConf est lent, vous serez plus crédible si vous dites que lire les prefs d'une appli nécessite l'accés à plusieurs petits fichiers ce qui est lent plutot que si vous montrez du doigt le parsing xml. Y a aussi les communications IPC entre le démon et les applis qui sont pas forcément gratuites. Le fait que GConf soit un démon gomme un peu ce problème puisqu'une fois que le fichier est lu, la valeur des prefs est cachée en mémoire.
[^] # Re: Qt 4 à l'horizon !
Posté par gnumdk (site web personnel) . Évalué à 0.
Lors de la sortie de gnome 2, il m'a fallu des mois pour lacher mon gnome 1.4 tant la conf de mon desktop ramait avec gnome2.
http://l3lx202.univ-lille3.fr/~bellegarde/gnome.png(...)
que de souvenirs :(
Bon, sur le screenshot, on ne vois que deux panels mais il y en avait trois(un derriere le wine) et les deux tirroirs du hauts etait plein de sous tirroirs....
En essayant de repoduire la meme chose avec gnome2, je me retrouvais avec un desktop tres lent au démarrage. Vu que gnome stock la conf des panels dans gconf, j'ai pas mis longtemps a blamer gconf :D
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . Évalué à 1.
Je ne me plains pas, je ne l'ai jamais utilise ni mesure. En revanche, je sais que KDE a gagne du temps en optimisant la lecture de ses fichiers de conf et je ne vois pas de raisons pourquoi gnome n'aurait pas le me me probleme.
Si tu tapes dans une appli moyenne, tu atteinds vite la centaine de cle de configuration donc autant de xml a lire.
5 a 10 ms, je crois que c'est le temps pour lire toutes les config de tout KDE sur un ordinateur et disque dur lent. Ca inclut pas mal de fichiers differents. Si t'es vraiment inferieur a la ms sur ton temps de parsing, ca ne genera pas. Attention quand meme car l'utilisateur percoit un temps a partir de 50 ms a peu pres.
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 1.
5 à 10 ms, c'est le temps que met la tête de lecture du disque dur pour accéder à un fichier (en étant optimiste, vaut mieux tabler sur 10 à 20 ms sur de l'ide de base je pense). Donc si toutes les configs de KDE sont dans un seul fichier ou bien si tous ces fichiers sont contigus sur disque, l'ordre de grandeur que tu donnes est réaliste pour la parsing de toutes les configs de kde. Sinon, c'est 10ms * nb de fichier de config.
[^] # Re: Qt 4 à l'horizon !
Posté par un_brice (site web personnel) . Évalué à 1.
Mais de toutes manières, il reste que le parsing d'un xml est plus lent qu'un ini, et que cette diffèrence de vitesse risque fort d'être négligeable devant le reste du lancement d'une appli; surtout si gconfig garde en cache une image complète de sa "base registre" (comme un certain OS... ).
[^] # Re: Qt 4 à l'horizon !
Posté par wismerhill . Évalué à 1.
Et comment gconf il fait pour remarquer que j'ai modifié une option d'un fichier de config avec mon éditeur de texte (mcedit, pour être sur qu'il n'est pas lié à gconf)?
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par wismerhill . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par yoplait . Évalué à 4.
La principe de la base de registre Windows est de centraliser toutes les options de configuration dans quelques gros fichiers binaires facilement corruptible.
Moi non.
[^] # Re: Qt 4 à l'horizon !
Posté par tgl . Évalué à 3.
Bah je pense que c'est un point de vu d'utilisateur qui découle des similitudes de GUI entre gconf-editor et regedit, ça n'a rien de très étonnant, mais ça n'a effectivement rien de bien fondé non plus.
Sinon, pour ce qui est de la prise en compte à la volée de préférences éditées à la mano dans des fichiers, on pourrait techniquement l'envisager avec un démon comme FAM (File Alternation Monitor). Mais je ne pense pas que ce soit un objectif de GConf de prendre ça en compte (enfin je dis ça, j'en sais rien), ça me semble un peu court-circuiter la couche d'abstraction que justement il offre (quid si le backend des préférence est une BDD par exemple ?).
[^] # Re: Qt 4 à l'horizon !
Posté par yoplait . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par tgl . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par Lionel Fournigault . Évalué à 2.
KDE c'est 4 millions de lignes de C++ avec Qt qui factorise un max.
Re-ecrire KDE en gtk (donc en C pseudo objet) ca doit faire à la louche
10 millions de lignes, donc en commencant maintenant je pense qu'en
2020 le projet devrait sortir en beta... avec 100 000 tonnes de bugs.
[^] # Re: Qt 4 à l'horizon !
Posté par Erwan . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: Qt 4 à l'horizon !
Posté par Vivi (site web personnel) . Évalué à 2.
http://mail.gnome.org/archives/gconf-list/2003-December/msg00002.ht(...)
http://mail.gnome.org/archives/gconf-list/2003-December/msg00006.ht(...)
(mais bon tu es au courant ;)
[^] # Re: Qt 4 à l'horizon !
Posté par un_brice (site web personnel) . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . Évalué à 3.
J'espere aussi que la transition se fera mais faut pas croire que ca sera rapide. Peut-etre pour KDE4. Il n'a pas fallu beaucoup de temps pour faire DCOP, mais certaines finitions prennent du temps et de l'experience d'utilisation. Il faut laisser DBUS maturer encore.
[^] # Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau . Évalué à 3.
Pour moi, DBus mature et utilisé par beaucoup de monde, ça va prendre au moins 1 an probablement 2 ou 3, ça laisse le temps de voir venir :)
Pour les avantages nets, si GNOME, Rox ou d'autres trucs l'utilisent, l'interopérabilité me parait être un énorme avantage de DBus par rapport à DCop. Si les couches basses du système indiquent ce qu'il se passe en utilisant DBus (udev, hal & co), ça rend aussi DBus très intéressant (même si dans ce cas là, DBus peut être utilisé en complément de DCOP).
Enfin en ce qui concerne un éventuel remplacement de DCOP par DBus, j'avais l'impression que le but c'était que ça soit quasiment transparent pour les applis utilisant DCOP (ie qu'il y ait un wrapper reprenant l'api de DCOP pour DBus).
[^] # Re: Qt 4 à l'horizon !
Posté par Vivi (site web personnel) . Évalué à 1.
hum ... comme quoi ?
[^] # Re: Qt 4 à l'horizon !
Posté par dcp . Évalué à -3.
# Re: Qt 4 à l'horizon !
Posté par golum . Évalué à -1.
juste pour signaler à Zenitram que je lui ai posté quelque url au sujet des comparaisons GUI sur le dernier thread sur Trolltech
http://linuxfr.org/2004/04/13/15983.html(...)
Moinssez pas trop siouplé
[^] # Re: Qt 4 à l'horizon !
Posté par calandoa . Évalué à 1.
http://linuxfr.org/comments/393526.html(...)
# Re: Qt 4 à l'horizon !
Posté par calandoa . Évalué à 1.
«Qt 4.0 will be previewed by Haavard Nord and Jasmin Blanchette as part of the upcoming Qt Developers Conference in Boston. Admission is only $100 but fewer than 30 seats remain.
Agenda at: http://www.ics.com/qtmeetings/agenda.html(...)
Reserve your seat now at: https://www.ics.com/qtmeetings/registration.html(...)»
Le « only $100 » a juste eu un peu de mal à passer...
[^] # Re: Qt 4 à l'horizon !
Posté par jujubinche007 . Évalué à 1.
ben il semble que non ....
[^] # Re: Qt 4 à l'horizon !
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
http://javaone.medialiveinternational.com/sf2004/registration.html(...)
[^] # Re: Qt 4 à l'horizon !
Posté par Erwan . Évalué à 2.
Toi, t'es jamais alle en conference ? En general, quand ca ne coute que 100$ les entreprises (qui sont la principale cible, en fait) ne prennent pas ca au serieux, et n'envoient au mieux qu'un pauvre stagiaire.
# Re: Qt 4 à l'horizon !
Posté par locnet . Évalué à 0.
J'ai lu que Gnomemeeting 2.0 utilisera Qt au lieu de GTK.
C'est un mouvement général ?
A quand Gimp sous QT ?
[^] # Re: Qt 4 à l'horizon !
Posté par dcp . Évalué à 3.
...Update: It was of course the traditional 1st April Fool!...
[^] # Re: Qt 4 à l'horizon !
Posté par eolyte . Évalué à 1.
# Re: Qt 4 à l'horizon !
Posté par elamapi . Évalué à 2.
Pourquoi uniformiser ?
Certaine personne aime le look'n'feel KDE, d'autre préfère Gnome. C'est bien que les deux existe. En plus la "concurence" (même involontaire) entre Gnome et Kde fait que chacun essais de faire mieux que l'autre donc tout benef pour l'utilisateur.
C'est bien la diversité.
Que penseriez vous si, sous votre linux, il n'y avait plus qu'un WM, Knome par exemple, et qu'une seule appli traitement de texte (ba vi, on va uniformiser ca aussi) etc, etc, etc ... ca reviendrai pas a faire un "Gros OS" a la windows ou tout est uniformisé (avec les conséquence qu'on connait).
[^] # Re: Qt 4 à l'horizon !
Posté par Lionel Fournigault . Évalué à 1.
crados et ça fait rire les windowseux. Vouloir faire un espece de merge entre KDE et
Gnome n'est pas la bonne démarche. A mon humble avis c'est soi l'un soi l'autre.
Personnellement j''utilise KDE avec que des applis KDE uniquement comme la plupart
des gens qui utilisent KDE. Et si je devais utiliser Gnome je n'utiliserai que des applis Gnome toujours pour la coherence et l'homogénéité.
J'ai l'impression que la demande de merge vient essentiellement des gens qui utilisent Gnome. Enfin bon.
[^] # Re: Qt 4 à l'horizon !
Posté par elamapi . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par wismerhill . Évalué à 2.
Je préfère généralement utiliser une appli KDE, mais quand il n'y en a pas ou qu'elle ne me convient pas j'en utilise une autre.
Et je connais beaucoup de personnes qui utilisent k3b sous gnome (et pourtant utiliser les appli KDE hors de KDE est assez lourd).
[^] # Re: Qt 4 à l'horizon !
Posté par Lionel Fournigault . Évalué à 0.
Oui, et ya aussi kopete, konqueror, kontact, kdevelop, kate, kstars
et la ça va etre très lourd sous Gnome (rire).
[^] # Re: Qt 4 à l'horizon !
Posté par wismerhill . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par gnumdk (site web personnel) . Évalué à 3.
MDR
Nan, le problème que j'avais sous gnome se repete encore sous kde. Il me manque des applis et je dois charger parfois un truc en gtk(gimp). Heureusement que le theme gtk utilisant qt aide un peu.
[^] # Re: Qt 4 à l'horizon !
Posté par peau chat . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par yoplait . Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
(ça c'est du troll de premier choix ;-))
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.