Qt-4.4.2 vient de sortir, juste des corrections de bugs, voici les changements : http://trolltech.com/developer/resources/notes/changes/chang(...)
Pour ce qui est de la futur version Qt-4.5, ça avance et ça va être que du bon :
- Le support Cocoa est maintenant dans la futur version 4.5 :
http://labs.trolltech.com/blogs/2008/09/22/cocoa-news-and-vi(...)
http://labs.trolltech.com/blogs/2008/06/09/second-cocoa-alph(...)
Pour rappel, Qt utilise jusqu'à maintenant l'API carbon http://en.wikipedia.org/wiki/Carbon_(API)
Celle-ci n'est pas compatible 64bits contrairement à Cocoa et est un peu a l'abandon par Apple d'apres ce que j'ai compris (Carbon etait avant tout la pour permettre la transition entre MacOS 9 et X) http://en.wikipedia.org/wiki/Cocoa_(API)
Concrètement, Qt-4.5 sera donc parfaitement intégré à MacOS X, ce qui n'était pas tout a fait le cas avec les précédentes versions de Qt
- Qt-4.5 sera encore plus rapide au niveau de l'affichage sous Windows
http://labs.trolltech.com/blogs/2008/09/22/sorry-guys/
D'autres optimisations sont a prevoir egalement : http://labs.trolltech.com/blogs/2008/08/06/in-the-flow/
- Qt-4.5 devrait améliorer l'affichage des polices et se rapprocher de GTK+ au niveau de l'aspect des polices
http://labs.trolltech.com/blogs/2008/09/01/subpixel-antialia(...)
http://labs.trolltech.com/blogs/2008/08/28/font-anatomy/
- La couche réseau sera plus performante avec l'ajout d'un système de cache
http://labs.trolltech.com/blogs/2008/08/04/network-cache/
- QTextDocument permettra l'export au format OpenDocument (ODF) (mais pas la lecture)
http://labs.trolltech.com/blogs/2008/08/06/opendocument-form(...)
- QWebKit va être amélioré avec le support des plugins et donc notamment de Flash
- On pourra enfin fermer individuellement les tabs d'un QTabBar
http://labs.trolltech.com/blogs/2008/07/02/some-qtabbar-qtab(...)
Il etait temps...
- Pour rappel, QGtkStyle fera partie de Qt-4.5
http://linuxfr.org/~tanguy_k/27173.html
- Cette liste n'est pas exhaustive
D'après ce que j'ai compris, une première version (Technology Preview) de Qt-4.5 devrait être disponible d'ici quelques semaines.
En revanche je n'ai pas d'infos sur la date de sortie de Qt-4.5, surement pour la fin de l'année.
Pour ceux qui avaient encore un doute : Qt est tout simplement devenu avec le temps le meilleur toolkit graphique tous langages et plateformes confondus.
Journal Sortie de Qt-4.4.2 + des infos sur Qt-4.5
23
sept.
2008
# Animation API (Qedje ?)
Posté par lamiducampeur . Évalué à 2.
[1] http://labs.trolltech.com/blogs/2008/09/18/repeat-after-me-t(...)
[2] http://dev.openbossa.org/trac/qedje
[3] http://labs.morpheuz.eng.br/blog/01/08/2008/qedje-init/
[4] http://labs.morpheuz.eng.br/blog/21/08/2008/plasmoid-with-qe(...)
[5] http://trolltech.com/qtdevdays2008/technical
[^] # Re: Animation API (Qedje ?)
Posté par Gof (site web personnel) . Évalué à 3.
QEdge n'est donc pas cette mistérieuse API.
Et puis rien est encore sûr concernant l'intégration de l'API d'animation dans Qt 4.5
# Choix
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
[^] # Re: Choix
Posté par sanao . Évalué à 5.
[^] # Re: Choix
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Ensuite, tu parles justement de "style" par opposition à "natif"...
Enfin, personnellement, depuis une dizaine d'année, je n'utilise que des applis GTK, et des QT que très sporadiquement (genre, sur une machine d'ami, lors du premier log in sur une machine d'université, etc), donc je n'ai pas trop d'expérience à ce niveau pour dire ce qui est bien ou ne l'est pas. Disons que j'ai un biais ancestrale qui penche pour GTK.
[^] # Re: Choix
Posté par CrEv (site web personnel) . Évalué à 7.
C'est étrange comme c'est souvent chez les personnes aimant GTK...
Le truc c'est que ça date souvent de l'époque ou qt était pas totalement libre (alors que c'est fini depuis un moment...)
C'est graphiquement bien, surtout avec les ajouts de qt4.5 (même si celui-ci n'est pas encore vraiment là)
C'est techniquement bien, un modèle object bien foutu (pour du C++ c'est impec)
C'est très vaste.
En gros, y a-t-il des arguments objectifs contre Qt ou pour GTK ?
(à part openoffice et firefox hein parce que bon...)
[^] # Re: Choix
Posté par Pinaraf . Évalué à 5.
OpenOffice dispose dans sa VCL d'une abstraction au toolkit sous-jacent. Ce n'est donc pas un argument.
Firefox utilise XULrunner, dont un portage en Qt est en cours aussi. Prochainement, cela ne devrait donc plus être un argument (sauf si le port est à nouveau abandonné, comme cela s'est déjà produit)
[^] # Re: Choix
Posté par Anonyme . Évalué à 4.
Est-ce que "Je programme en C" ca te va comme argument ? Promis le jour où il y a un binding C (officiel) pour Qt j'essaie pour voir.
PS: ce message n'est pas une incitation au troll C Vs C++ ou même PI Vs POO, c'est juste que moi j'aime le C, c'est le langage avec lequel je suis le plus à l'aise, et c'est avec lui que je veux programmer lorsque je fais cela pour le plaisir sur mon temps libre (pour un projet professionnel le langage est choisi sur d'autres critères que mes goûts personnels). GTK avec son très grand nombre de binding permet à chacun d'en faire de même quelque soit ses goûts en matière de programmation.
[^] # Re: Choix
Posté par CrEv (site web personnel) . Évalué à 3.
Ha mais tout à fait et même je l'aprouve.
Cette raison je la comprend très bien (qui n'a pas choisi au moins une fois un toolkit / framework en fonction du langage qu'il connait ?)
(Celle que je comprend moins c'est GObject mais bon...)
Pour ce qui est de binding, avec Qt (donc en C++) + les binding python, ruby, java (perl je sais plus) même si ça ne couvre pas tous les langages et qu'il y en a surement plus de supportés en GTK, je trouve ça déjà pas mal.
[^] # Re: Choix
Posté par Anonyme . Évalué à 7.
Je me rend compte que j'ai oublié les smileys dans ma première phrase, du coup j'ai l'air vindicatif alors que je voulais sonner cynique ^^;
@tanguy_k
Le coup du binding C était une boutade (je sais j'ai oublié les smileys ^^), j'avais déjà vu le binding C expérimental cité un peu après ton message, c'est pour ca que j'avais précisé "officiel", je n'ai certainement pas l'intention de me lancer dans un dev, même pour le fun, en reposant sur un truc aussi peu pérenne (et peu abouti au passage)
@sanao
J'avais bien précisé que je ne voulais pas lancer de troll à ce sujet, mais bon je vais essayer de te répondre quand même: J'ai en effet quelques soucis d'accointance avec la POO et particulièrement le C++.
- Pour la POO, c'est simple, il y a déjà en effet on va dire "les goûts et les couleurs". Pour moi, il est plus facile, plus naturel, de raisonner sur "une combinaison complexe d'élements simples" plutôt que sur "une combinaison simple d'élements complexes".
Explications: le C, c'est des fonctions, avec des entrés/sorties, un retour, et code séquentiel dedans. Un bon codeur en C écrivant des fonctions relativement courtes, le programme ne sera alors qu'un ensemble de petites briques avec des relations inter et intra niveau.
Chacune de ses briques étant donc algorithmiquement indépendantes, je peux alors me concentrer individuellement sur chaque brique sans avoir à me soucier des autres briques et surtout sans monopoliser une partie de ma concentration sur des problèmes d'héritage, de surcharge, de constructeur de recopie, etc. Pouvoir travailler de cette manière est pour moi essentiel afin d'obtenir un code robuste et aisément maintenable.
Bon maintenant, je me doute bien que je n'ai pas vraiment le profile type du développeur de SSII. Dans ce que je programme en (très) gros, 60% c'est de l'appli en ligne de commande, 25% c'est du code noyau, 10% c'est du code très bas niveau (comprendre par là en assembleur (aussi bien coté noyau qu'utilisateur)), et 5% de GUI (et je suis gentil en disant 5% ^^). Et quand je programme, même pour le fun sur mon temps libre, je fais toujours ca à l'ancienne: d'abord une specification fonctionnelle, puis spécification architecturale en couche, puis les algorithmes des différents composants, puis enfin je code ces différents composants des couches les plus basses vers les couches les plus hautes en validant toujours les composants d'une couche avant de passer à une couche supérieure à l'aide de tests automatisés et de jeux de données.
Mais même moi qui suit un peu un extremiste du développement l'ancienne (voir le paragraphe juste au dessus ^^), je reconnais que dans certains cas la POO peut apporter quelque chose au processus de développement. Il m'arrive d'ailleurs de l'utiliser occasionnellement (python/ruby).
Le problème que j'ai avec beaucoup de développeurs POO (les javateux en particulier) c'est que comme le dit un dicton anglais, quand on a un marteau, tous les problèmes ressemblent à des clous. Le nombre de fois où j'ai vu l'artillerie lourde objet être utilisée pour un (relativement) petit développement où du fonctionnel aurait donné un code au design plus simple, plus lisible et plus maintenable... le nombre de fois où j'ai vu java utilisé pour un développement dont il est complètement crétin de se farcir une machine virtuelle dans l'environnement d'exécution...
Si on avait inventé un language parfait pour tous les usages, ca se saurait. On dispose de tout un tas de languages de programmation, et développer (pour moi) c'est aussi savoir choisir le bon outil pour le bon développement. Bien sur on ne peut pas maitriser tous les languages, mais avoir à sa disposition un panel de 2-3 languages qui se complètent c'est pas superflue.
- Pour le C++, là aussi c'est simple, c'est clairement *TROP* objet ! C'est sûrement très intéressant et très à la pointe en terme de paradigme objet d'un point de vue théorie des langages, mais d'un point de vue pratique ca fait un peu usine à gaz desfois...
Par exemple, il m'est arrivé de devoir me plonger dans du code C++ (pas écrit pas moi) où j'ai mis un temps fou à m'y retrouver parce que les instanciations de template avec héritage multiple... bonjour l'aspirine... À l'inverse, quand je me suis m'y à coder pour le noyau linux, je m'y suis très vite retrouvé, pourtant c'est pas ridicule comme programme (et pas écrit par moi non plus ^^), mais limiter un minimum la complexité semantique d'un langage pour ne conserver que ce qui apporte vraiment, c'est loin d'être une mauvaise idée, surtout en informatique où ca parait pas idiot de chercher à se concentrer plus sur l'algorithme que sur le langage lui même.
J'avais aussi jeté un coup d'oeil à Objectiv-C, je trouve que leur paradigme objet est déjà plus raisonnable. Bon par contre la syntaxe est à gerber.
Pour ce qui est des langages "managés", type JAVA ou C#. Je trouve ca très intéressant (enfin surtout le côté managé, parce que bon l'objet hein... ^_^). Pour du userland, la robustesse, la sécurité et les possibilités d'introspection qu'ils apportent c'est vraiment un plus non négligeable. Le problème depuis l'avènement de ces langages managés, c'est que beaucoup croient qu'il n'est plus maintenant nécessaire de comprendre comment fonctionnent les couches basses d'un ordinateur et encore moins de faire attention à comment on implémente les algorithmes car de toute facon la machine virtuelle passe tout ca dans sa moulinette avant l'exécution.
Moi je pense réellement que ca apporte quelques choses de maitriser les couches basses (et donc de faire du C), même si après on ne sans sert pas en JAVA. Ca impose une certaine rigueur ensuite bénéfique même pour les langages de plus haut niveau.
Genre je donne des cours de prog, je fais réimplenter en JAVA un client FTP (sans utiliser d'API de haut niveau, oui c'est réinventer la roue, mais cette dans un but pédagogique). J'ai 2 types d'élèves, des 3ème année d'ingé, pas des informaticiens mais des gars qui ont bouffés du JAVA pendant leur formation et pas des quiches niveau capacités intellectuelles, et des 2ème année d'IUT élec, qui n'ont jamais fait de JAVA (sauf ceux qui en ont fait chez soi sur leur temps libre) et donc qui doivent aussi appréhender le JAVA par la même occasion. Sauf que ces derniers se sont farcis la programmation de micro-controlleur en C et en ASM par le passé, et c'est un secret pour personne qu'implémenter un protocole réseau ca demande d'être rigoureux. Je vous laisse deviner qui s'en sort mieux au final...
De par les facilités que ces langages apportent, beaucoup pensent qu'on a plus besoin d'être aussi rigoureux et attentif qu'avant pour développer, et bien souvent, à l'issue des formations, au final ce qu'on a formé c'est pas des développeurs mais des pisseurs de code. Mais bon, comme le pisseur de code en JAVA ou C# est très recherché ces derniers temps dans le milieu professionnel (j'ai déjà eu ca en job hein ^^, on a un mois pour torcher une appli pour la refiler au client et encaisser le chèque puis passer au client suivant, au pire si plus tard le client se rend compte de bug on factuera la maintenance du code ^^). On va dire que le marché à les développeurs qu'il mérite ^^
[^] # Re: Choix
Posté par sanao . Évalué à 3.
Cela permet non seulement de bien faire les choses, mais également de savoir si l'outil que l'on utilise est adapté à la situation et selon les cas, le langage peut être aussi différent que C, C++, Python, Java ou simplement Bash.
En ce qui me concerne, je réalise mes développement perso généralement avec Qt en C++ et je suis très satisfait du rapport entre la performance et la facilité de codage/maintenance.
Concernant ta remarque sur ta relecture de code en C++ avec , cela vient peut être du fait que le code est compliqué (et non complexe) pour pas grand chose. Cela arrive bien souvent (et avec tous les langages) lorsque des personnes codent en ne sachant pas vraiment se qu'ils font ou lorsqu'ils sont pressés par le temps et utilisent une technologie qu'ils ne maîtrisent pas vraiment.
[^] # Re: Choix
Posté par Anonyme . Évalué à 2.
@tout le monde
Vous pensez quoi de VALA ? Ca ressemble à de la POO minimaliste, c'est-à-dire avec juste ce qu'il faut pour développer des GUI, le tout avec une syntaxe à la C. J'ai bien envie de tester, car sur la papier, cela pourrait bien parfaitement me convenir ponctuellement pour de la GUI.
[^] # Re: Choix
Posté par sanao . Évalué à 4.
Maintenant c'est ma vision des choses et comme on dit, les goûts et les couleurs cela ne se discute pas.
En tout cas en ce qui me concerne si j'adore Qt4 c'est principalement pour la qualité et l'extrême richesse de la bibliothèque.
[^] # Re: Choix
Posté par tanguy_k (site web personnel) . Évalué à 9.
AMHA Il n'y aura jamais de binding C pour Qt. Mapper Qt qui utilise intensivement le modèle objet par un système procédurale serait à mon avis beaucoup trop compliqué et donnerait un truc bancale.
Laissons le langage C pour le noyau, les drivers ect...
Pour les interfaces graphiques, des langages comme C++, Python, Java, C#, Ruby ect... sont infiniment plus adaptés. Ca tombe bien, il y a des bindings Qt pour ces langages.
Les bindings Python (PyQt) et Java (Qt Jambi) sont considérés comme stables et sont régulièrement utilisés par des applications, en revanche les bindings C# et Ruby ne sont pas encore vraiment utilisés et doivent être surement encore trop jeune.
Pour moi (je vais me faire moinser, tant pis), le fait que le projet GNOME souhaite à tout prix utiliser le langage C est une hérésie. Et Miguel de Icaza a du bien s'en rendre compte, d'où la création de Mono.
Bref pour les interfaces graphiques, il est temps d'abandonner le C qui date d'il y a 40 ans pour un truc plus moderne comme Python, le résultat n'en sera que meilleur.
Pour le web ca fait longtemps que l'on ne fait plus de CGI en C alors admettons que le C est aussi dépassé pour la création d'interfaces graphiques.
[^] # Re: Choix
Posté par Bapt (site web personnel) . Évalué à 1.
J'adore les gens qui assène des vérité qu'ils sortent d'on ne sais où ?
c'est marrant mais la plupart des applis gui en C qui marche très bien il y en a un paquet, mais que je trouve ça bien que des bon devs C s'attaque aussi à du GUI et me ponde des application qui sont très performantes, je ne parle pas forcément des applis gtk, mais des applis E17 par exemple emphasis ou exhibit... Laisse les gens qui aiment le C développer dans leur langage de prédilection et arrête avec tes conneries d'hérésies.
j'aime les belles affirmations pourries :
Laissons le langage C pour le noyau, les drivers ect... je te signale qu'il y a des gens aussi qui utilise le C++ pour faire ce genre de choses : noyau, driver, etc.
[^] # Re: Choix
Posté par tanguy_k (site web personnel) . Évalué à 7.
Ma propre expérience + celle de pas mal d'autres dev.
> la plupart des applis gui en C qui marche très bien il y en a un paquet
Et ben dit toi que si ces applis avaient été développé en Python par exemple, et ben les développeurs auraient été plus vite ou/et auraient ajouté plus de fonctionnalités.
C'est comme ça, j'invente rien, n'importe quel dev qui a fait du C et du Python te dira que l'on développe plus vite en Python.
Il est par exemple aussi communément admis que l'on développe 2x plus vite en Java qu'en C++ (source : Bruce Eckel).
Ca veut pas dire que le C est un mauvais langage ou que les applis codées avec sont mauvaises, ça veut simplement dire que dans pas mal de cas (de plus en plus avec le temps), il est tout simplement inadapté.
Tout comme un jour C++, Java, C#... seront surement replacés par des langages plus performants.
Libre après aux gens d'utiliser des langages moins adaptés, je vais pas aller les bruler hein ! j'ai longtemps développé en C mais je suis pas marié avec un langage en particulier : j'utilise celui qui semble être le plus adapté pour ce que je veux faire ./
[^] # Re: Choix
Posté par zebra3 . Évalué à 3.
D'ailleurs, il est également temps d'abandonner Unix qui est aussi vieux. Passons tous à Vista puis Seven, ça c'est l'avenir !
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Choix
Posté par tanguy_k (site web personnel) . Évalué à 2.
Ma phrase signifiait pas que "c'est vieux donc c'est nul" mais qu'il y a eu des avancés importante entre le langage C et les langages dit modernes tout comme entre la Ford T et la dernière Renault.
D'un autre coté je me sers tous les jours de la vaisselle de ma grand mère, on a pas encore fait mieux, et pourtant dieu sait que ça date !
[^] # Re: Choix
Posté par _tty . Évalué à 1.
Ça a déjà été fait apparemment, mais je ne sais pas ce qu'il en est :
http://dot.kde.org/1003877941/
[^] # Re: Choix
Posté par tanguy_k (site web personnel) . Évalué à 2.
De toute façon l'intérêt est franchement pas évident vu que GTK+ / C existe.
[^] # Re: Choix
Posté par Gof (site web personnel) . Évalué à 2.
Qt est plus qu'une bibliothèque graphique c'est un framework comlet.
Framework qui utilise à fond le paradigme object.
Si c'est juste pour pouvoir avoir le même look, il suffit d'utiliser Gtk et en:GTK-Qt
[^] # Re: Choix
Posté par fredix . Évalué à 1.
Pour après se plaindre que le desktop rame ?! Moi je suis content que GNOME se base sur un langage compilé bas niveau, ce qui garanti un minimum de perf sur une petite machine (notebook ou autres).
Libre à toi de développer une appli GTK+ ou GNOME en python, c'est l'intérêt même des bindings, sauf qu'un langage script c'est bien pour développer un petit soft mais pas pour un gros projet qui a besoin d'être réactif et d'occuper peu de ressource.
[^] # Re: Choix
Posté par windu.2b . Évalué à 4.
C'est pour ça que Gnome commence à inclure des applis codées en Mono ?!?
[^] # Re: Choix
Posté par fredix . Évalué à 0.
De toute manière GNOME incluait bien avant Mono des applications en Python, ce qui certes n'aide pas à la réactivité mais c'est un choix de certains développeurs, la grande majorité des applications sont en C/C++.
[^] # Re: Choix
Posté par wismerhill . Évalué à 3.
[^] # Re: Choix
Posté par reno . Évalué à 2.
Scala me parait bien plus adapté: ça tourne sur la JVM (donc a priori plus performant), c'est statiquement typé avec inférence de type donc moins verbeux que Java ou C++, mieux connu que Vala..
Oups, c'est pas vendredi, ok je --> []
[^] # Re: Choix
Posté par Guillaume Denry (site web personnel) . Évalué à 8.
D'ailleurs je crois qu'on peut dire que Qt4 n'a aucun équivalent aujourd'hui en matière de largeur de spectre fonctionnel couvert : GUI, multimédia (avec phonon), bureautique, structures de données puissantes, gestion de l'unicode, gestion des traductions, gestion de la documentation (depuis peu), gestion de webkit, etc.
C'est un véritable couteau suisse.
[^] # Re: Choix
Posté par Gof (site web personnel) . Évalué à 2.
[^] # Re: Choix
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Par exemple, lorsqu'on ouvre une combobox de valeurs pour n'importe quelle propriété, sa largeur (la liste de défilement) est celle de la cellule de valeur, et souvent on ne voit pas entièrement les intitulés des valeurs et il faut alors retailler le formulaire, ou régler la taille des colonnes de l'éditeur. Du coup, je suis constamment en train de retailler des trucs.
# Troll
Posté par tanguy_k (site web personnel) . Évalué à 2.
merde le troll prend pas :/
[^] # Re: Troll
Posté par jjay . Évalué à 10.
[^] # Re: Troll
Posté par Maclag . Évalué à 10.
C'est très réducteur!
Autant dire qu'Emacs est un éditeur de texte alors!
(et vivement vendredi...)
[^] # Re: Troll
Posté par abramov_MS . Évalué à 2.
[^] # Re: Troll
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: Troll
Posté par Gof (site web personnel) . Évalué à 1.
[^] # Plate-forme
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à -1.
C'est pour éviter l'accord des mots composés ?
# widgets transparents
Posté par tanguy_k (site web personnel) . Évalué à 2.
Donc encore plus de bling bling, je crois que notre pote Sarko va etre content :p
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.