Articles précédents : Articles
- [28] Sortie de KDE 3.2.2
- [22] S'afficher avec son Mozilla
- [76] Netfilter porte plainte contre Sitecom pour non-respect de la GPL
- [20] Deux éminentes personnalités informatiques en France... en 2005 ! (à vos agendas)
- [53] On remet les gants pour le deuxième round dans le combat européen sur les brevets logiciels
- [26] Libr'east : changement de lieu
- [68] Une longue interview de Trolltech
- [48] Le Brésil fait des économies grâce à Linux
- [7] Les logiciels libres : éthiques et pratiques
- [12] Sortie de Digikam 0.6.1
Liens connexes
- L'article sur Qt4 (863 hits)
- Le "Qt Quarterly" de ce trimestre (312 hits)
Dépêche modérée par
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.
![[en]](../../../images/en.png)
L'article sur Qt4 (863 hits)-
Le "Qt Quarterly" de ce trimestre (312 hits)
> Lire la dépêche (89 commentaires, moyenne: 1,5).
-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.
Re: Qt 4 à l'horizon !
C'est une bonne nouvelle, mais y a-t-il des changements de licences ?
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 (Jabber id, page perso, ) le 20/04/2004 à 15:56. (lien). Évalué à 3.La réponse à ta question est là : http://linuxfr.org/2004/04/13/15983.html(...)
-
[^]Re: Qt 4 à l'horizon !
Posté par BiBite () le 20/04/2004 à 21:41. (lien). Évalué à 1.Je me pose une autre question qui sort un peu du cadre de cet article mais.. Imaginons que j'achète une licence Qt pour Windows. Est-ce que j'ai le droit de développer un logiciel GPL basé sur Qt ?
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 (page perso, ) le 21/04/2004 à 00:20. (lien). Évalué à 1.Oui et oui, par exemple, PSI est un client Jabber multi-plateforme (Linux/Win/Macosx) qui est codé en QT. Il suffit une license développeur sur la plate-forme non-libre pour pouvoir compiler/distribuer le programme.
http://psi.affinix.com/(...)
-
[^]Re: Qt 4 à l'horizon !
Posté par Piksou () le 21/04/2004 à 07:20. (lien). Évalué à 2.Oui et non
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 () le 21/04/2004 à 11:31. (lien). Évalué à 0.Bof, tu est sur de toi?
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 () le 21/04/2004 à 12:29. (lien). Évalué à 1.La GPL dit que t'as pas le droit de te linker sur des biblios proprios sauf si elles font partie intégrante du système d'exploitation. QT n'entre clairement pas dans cette catégorie là à mon avis.
Perso, je connais pas beaucoup de softs GPL pour Windows utilisant QT...-
[^]Re: Qt 4 à l'horizon !
Posté par Piksou () le 21/04/2004 à 14:23. (lien). Évalué à 2.tout à fait
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 !
-
-
-
[^]Re: Qt 4 à l'horizon !
Posté par VACHOR (page perso, ) le 20/04/2004 à 16:01. (lien). Évalué à 1.La version 4 est mieux ... cela ressemble à du Java !
--> 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 laurent belmonte (Jabber id, page perso, ) le 20/04/2004 à 16:09. (lien). Évalué à 1.J'avais une vrai question mais apparament elle ne plait pas vu que j ai été moinsé. Donc je la reformule :
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 (Jabber id, ) le 20/04/2004 à 16:26. (lien). Évalué à 1.http://www.trolltech.com/download/qt/x11.html(...)
par contre je sais pas si les sources de QT4 sont dispo
-
[^]Re: Qt 4 à l'horizon !
Posté par Philippe Fremy (page perso, ) le 21/04/2004 à 07:38. (lien). Évalué à 5.En general, Trolltech n'aime pas faire du vaporware et est assez protecteur de ses sources tant qu'elle n'ont pas atteint un etat stable. A vue de nez, je dirai qu'on devrait voir des snapshots arriver a partir de cet ete.
-
-
[^]Re: Qt 4 à l'horizon !
Posté par peau chat () le 20/04/2004 à 16:39. (lien). É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)
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 (page perso, ) le 21/04/2004 à 19:50. (lien). Évalué à 0.tout à fait !
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 () le 21/04/2004 à 19:57. (lien). Évalué à 1.jamais entendu parler et jamais évoqué par les mecs de QT quand on les interroge.
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 Fremy (page perso, ) le 22/04/2004 à 08:09. (lien). Évalué à 2.Il pense probablement a la DLL de windows gerant les styles sous windows XP. La dependance est configurable donc ca n'est pas un obstacle pour livrer Qt4 sous windows.
-
[^]Re: Qt 4 à l'horizon !
Posté par Piksou () le 22/04/2004 à 11:15. (lien). Évalué à 3.En même temps si c'est une DLL de windows ne se pose pas... ?
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 !
Et les sources de tout ca, c'est ou ?
-
[^]Re: Qt 4 à l'horizon !
Posté par Brice Arnould ( un_brice ) (page perso, ) le 20/04/2004 à 16:18. (lien). Évalué à 3.Il faut un module spécifique pour l'accès. Cf http://kadreg.free.fr/ipot/(...) (lis bien le disclaimer par contre: c'est très expérimental).
--
Respect à RMS.-
[^]Re: Qt 4 à l'horizon !
Posté par Epsos (page perso, ) le 20/04/2004 à 16:22. (lien). Évalué à 1.Excellent cette page ! :-)
-
[^]Re: Qt 4 à l'horizon !
Posté par Brice Arnould ( un_brice ) (page perso, ) le 20/04/2004 à 16:40. (lien). Évalué à 1.Ouais, enfin c'est quand même un peu lourdingue parce que pour avoir la version pour un 2.6, il faut l'installer pour un 2.4 et ensuite télécharger la version suivante, qui à été écrite en 1995 mais n'est disponible qu'en 2010 pour des raisons de cohèrence. En plus, il est distribué sous GPL 3.0 ce qui fait qu'on a pas le droit de distribuer des binaires liés à Linux (ça ferait vraiment une valeur ajoutée à la Mdk). Et ça c'est sans parler du buffer overflow qui menace la cohésion de l'espace-temps et n'est fixé que dans les versions Hurd... paske l'auteur des précédentes n'était pas né à l'époque ou elles étaient utiles et qu'il ne peut céder aucun droit sur le code qu'il n'avait pas encore écrit.
--
Respect à RMS.-
[^]Re: Qt 4 à l'horizon !
Posté par Alexandre LISSY (Jabber id, ) le 21/04/2004 à 07:48. (lien). Évalué à 1.t'as été acheter du pain ?
-
[^]Re: Qt 4 à l'horizon !
Posté par Brice Arnould ( un_brice ) (page perso, ) le 22/04/2004 à 17:48. (lien). É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.--
Respect à RMS.
-
-
-
-
Re: Qt 4 à l'horizon !
Le coup du foreach de Qt4 pour faire des choses du genre
foreach (QString s, list)
sum += s.length();
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 (page perso, ) le 20/04/2004 à 15:51. (lien). Évalué à 1.est bien sympathique aussi, c'est vraiment dommage que le c++ (standard) ne permette pas de faire ça.
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 (page perso, ) le 20/04/2004 à 16:02. (lien). Évalué à 1.Non, en c++ standard, le statement "foreach" n'existe pas.
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 (page perso, ) le 20/04/2004 à 16:03. (lien). Évalué à 1.nan, il y a std::for_each, mais c'est lourdissime à utiliser (il faut lui passer en argument la fonction à appliquer à chaque element du conteneur). Et si on veut faire une boucle for (;;) classique, alors il faut pouvoir declarer des iterateurs sur le conteneur, et leur type est bien souvent un truc monstrueusement long. Le foreach à la Qt permet d'eviter ces deux problèmes.
-
-
[^]Re: Qt 4 à l'horizon !
Posté par shbrol () le 20/04/2004 à 19:54. (lien). Évalué à 2.J'ai un peu de mal avec ton commentaire, et aussi avec les suivants. Je n'ai pas regarde comment c'est implementé, mais au vu de ton exemple, ca sent la macro a plein nez. Et ce genre de macro, ce n'est pas sympathique, c'est Mal (tm)(r) : tout se passe bien jusqu'a ce que tu commence a utiliser une autre bibiotheque qui définit elle aussi une macro du meme nom, ou pire encore une fonction...
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:
list text;
size_t length = 0;
for_each(text.begin(), text.end(), var(length) += bind(&string::size, _1));
ou encore, avec std::accumulate :
length = accumulate(text.begin(), text.end(), length, _1 += bind(&string::size, _2));
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 () le 20/04/2004 à 20:37. (lien). Évalué à 2.je me corrige moi-même...
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 (page perso, ) le 20/04/2004 à 20:44. (lien). Évalué à 1.Je crois que c'est pas une macro classique mais un truc geré par moc, comme pour les histoires de signaux et slots dans qt (enfin c'est juste une hypothèse)
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 !
Moi je voudrais juste savoir un truc : est ce qu'il y aura un jour un rapprochement entre gtk et qt au niveau de l'apparence parce que c'est pas que ce soit lourdingue que ça ne soit pas la même apparence mais presque.
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 () le 20/04/2004 à 18:51. (lien). Évalué à 1.La vrai question est je pense :
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 (Jabber id, page perso, ) le 20/04/2004 à 19:08. (lien). Évalué à 2.Et quand est-ce que tu recodes KDE en gtk ?
Tu as l'air motivé :)-
[^]Re: Qt 4 à l'horizon !
Posté par Michel Galle () le 20/04/2004 à 19:35. (lien). Évalué à 6.il n'est pas stupide d'espérer que kde utilise un jour gconf. bien plus que d'ironiser en lui demandant de "recoder kde en gtk" . (surtout que ce n'est qu'un détail enfin de compte, cela ne changera pas la profonde différence dans les choix d'interfaces, les prises de position qu'implique bonobo ou kparts, etc etc)
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 (Jabber id, page perso, ) le 20/04/2004 à 21:54. (lien). Évalué à 1.> 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".
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 Fremy (page perso, ) le 21/04/2004 à 07:50. (lien). Évalué à 1.Il existe un petit projet permettant a gtk d'utiliser le theme Qt courant. Sinon, la problematique de la couleur de fond a normalement ete resolu depuis longtemp. Maintenant, la couleur de fond est mise a jour pour gtk quand tu changes de theme/style sous KDE. Je suis surpris que ca ne soit pas le cas chez toi.
-
[+] [^]Re: Qt 4 à l'horizon !
Posté par calandoa () le 21/04/2004 à 08:44. (lien). Évalué à -2.Je trouve au contraire dommage d'essayer de les uniformiser. Déjà que les deux s'inspire de windows, il serait mieux qu'ils essayent d'évoluer dans leur propre direction plutôt que d'essayer de plaire de la même manière à la majorité des gens en se repompant mutuellement leurs particularités qui marchent. Et même si il ne s'agit que d'uniformiser l'aspect visuel, ça en dit long sur la direction que l'on souhaite leur faire prendre.
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 () le 21/04/2004 à 08:47. (lien). É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!
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 (page perso, ) le 22/04/2004 à 05:08. (lien). Évalué à 1....d'ailleurs cette fonction est encore presente, on peut la reactiver par une clef gconf.
-
-
-
-
[^]Re: Qt 4 à l'horizon !
Posté par Philippe Fremy (page perso, ) le 21/04/2004 à 07:48. (lien). Évalué à 4.Pourquoi ce serait pas Gnome qui utiliserait kconfig ? kconfig lui-meme n'a aucune dependance avec KDE et il est facile a une appli exterieure de relire les fichires de conf KDE qui sont bien organises.
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 () le 21/04/2004 à 07:54. (lien). Évalué à 2.> Pourquoi ce serait pas Gnome qui utiliserait kconfig ?
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 PasChauve PasOunet () le 21/04/2004 à 08:09. (lien). Évalué à 2.Est-ce que kconfig permet de "verrouiller" certaines options de config afin d'empêcher l'utilisateur de les modifier ?
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 Fremy (page perso, ) le 21/04/2004 à 19:17. (lien). Évalué à 1.kconfig permet en effet de verouiller des cles pour non-modification.
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 () le 21/04/2004 à 20:26. (lien). Évalué à 1.> 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.
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 () le 21/04/2004 à 20:28. (lien). Évalué à 1.J'ai oublié d'ajouter qu'il est parfaitement possible d'écrire des backends pour GConf n'utilisant pas du xml (utilisant des fichiers .ini par ex). Assez bizarrement, beaucoup de gens ne perdent pas une occasion de se plaindre du format de fichier utilisé par GConf, mais j'ai jamais vu de patch pour utiliser un autre format de fichier.
-
[^]Re: Qt 4 à l'horizon !
Posté par Guillaume Laurent (page perso, ) le 21/04/2004 à 22:48. (lien). Évalué à 0.> Comparé au temps d'accés à ton fichier de conf, le parsing xml est probablement pas très couteux.
"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 Fremy (page perso, ) le 22/04/2004 à 08:18. (lien). Évalué à 1.> Mouais... Comparé au temps d'accés à ton fichier de conf, le parsing xml
> 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 () le 22/04/2004 à 10:04. (lien). Évalué à 1.> Avec un fichier xml, le temps de chargement est necessairement plus long et les applications en patissent.
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 (page perso, ) le 22/04/2004 à 12:58. (lien). Évalué à 0.Tout ce que je peux dire, c'est que du point de vu utilisateur, gconf est lent, tres lent.
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--
Agogo
-
[^]Re: Qt 4 à l'horizon !
Posté par Philippe Fremy (page perso, ) le 22/04/2004 à 15:51. (lien). Évalué à 1.> Si vous voulez vous plaindre que GConf est lent
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 () le 22/04/2004 à 16:37. (lien). Évalué à 1.> 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
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 Brice Arnould ( un_brice ) (page perso, ) le 22/04/2004 à 17:57. (lien). Évalué à 1.Bouarf, y'a aussi le cache: les fichiers de config globale de KDE ont de fortes chances de se trouver dedans. Donc plus que le fichier de l'apli à chercher... (en priant très fort).
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... ).--
Respect à RMS.
-
-
-
-
-
-
-
-
[^]Re: Qt 4 à l'horizon !
Posté par wismerhill (page perso, ) le 21/04/2004 à 09:05. (lien). Évalué à 1.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) ?
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 () le 21/04/2004 à 09:14. (lien). Évalué à 2.Si tu veux modifier une option de config gérée par GConf, il faut le faire avec gconftool/gconf-editor ou tout autre outil linké sur GConf. GConf est essentiellement un démon, donc il peut cacher les valeurs de certaines prefs en mémoire, donc si tu édites sauvagement un de ses fichiers, rien ne te dit que la valeur que tu as mise dedans ne sera pas écrasée par le démon.
-
[^]Re: Qt 4 à l'horizon !
Posté par wismerhill (page perso, ) le 21/04/2004 à 10:12. (lien). Évalué à 2.Ça me plait pas ce truc. Je comprend pourquoi on le compare à la base de registre de windows.
-
[^]Re: Qt 4 à l'horizon !
Posté par yoplait () le 21/04/2004 à 15:10. (lien). Évalué à 4.Le principe de GConf est d'offrir un demon et une api pour modifier les fichiers de configuration, faciliter le travail des administrateurs en proposant une transparence reseau et la possibilite d'utiliser divers backend pour le stockage des options (base de donnees mysql, LDAP, fichiers xml comme c'est le cas par defaut, etc) et d'indiquer aux applications liees a GConf la notification instantanee des changements de configuration.
La principe de la base de registre Windows est de centraliser toutes les options de configuration dans quelques gros fichiers binaires facilement corruptible.
Je comprend pourquoi on le compare à la base de registre de windows.
Moi non.-
[^]Re: Qt 4 à l'horizon !
Posté par tgl () le 21/04/2004 à 16:34. (lien). Évalué à 3.Moi non.
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 Lionel Fournigault () le 21/04/2004 à 07:35. (lien). Évalué à 2.sympa le projet !!!
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 (page perso, ) le 22/04/2004 à 05:13. (lien). Évalué à 2.C'est completement stupide de calculer le nombre de lignes de KDE, d'additionner Konqueror avec Kmail, la dizaines de jeux qui fait partie de la distrib officielle et tout le reste.
-
-
-
[^]Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau () le 20/04/2004 à 20:07. (lien). Évalué à 1.À mon avis, il faut déjà que GConf cesse de dépendre de morceaux d'ORBit (implémentation de CORBA utilisée par GNOME) pour qu'il soit possible d'envisager de façon réaliste son utilisation par KDE.
-
[^]Re: Qt 4 à l'horizon !
Posté par Vivi (page perso, ) le 20/04/2004 à 20:47. (lien). Évalué à 2.La solution passera sans doute par DBus. Gconf peut utiliser DBus comme mécanisme d'IPC :
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 Brice Arnould ( un_brice ) (page perso, ) le 20/04/2004 à 21:02. (lien). Évalué à 2.Mais KDE ne veut pas utiliser DBus... (j'ai entendu parler d'un connecteur vers DCOP envisageable mais c'est tout)
--
Respect à RMS.-
[^]Re: Qt 4 à l'horizon !
Posté par Christophe Fergeau () le 20/04/2004 à 21:05. (lien). Évalué à 2.Je crois que ça dépend à qui tu demandes chez les gars de KDE. J'espère que quand DBus sera mature ils accepteront de l'utiliser à la place de DCOP si d'autres "gros" l'utilisent.
-
[^]Re: Qt 4 à l'horizon !
Posté par Philippe Fremy (page perso, ) le 21/04/2004 à 07:52. (lien). Évalué à 3.Pour que KDE accepte de se passer de DCOP, il faudra que DBUS propose des avantages nets, ce qui n'est pas encore le cas. DBUS pour l'instant n'est meme pas adopte pas Gnome, et ne permet pas de faire tout ce que fait dcop.
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 () le 21/04/2004 à 08:43. (lien). Évalué à 3.Oui oui, tout ce que tu dis était plus ou moins implicite dans mon « J'espère que quand DBus sera mature ils accepteront de l'utiliser à la place de DCOP si d'autres "gros" l'utilisent. »
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 (page perso, ) le 21/04/2004 à 11:56. (lien). Évalué à 1.et ne permet pas de faire tout ce que fait dcop.
hum ... comme quoi ?
-
-
-
-
-
-
[+] [^]Re: Qt 4 à l'horizon !
Posté par dcp (page perso, ) le 21/04/2004 à 08:28. (lien). Évalué à -3.gconf c'est le truc tout pourri qui essaye de faire comme la base de registres en pire ?
-
[+] Re: Qt 4 à l'horizon !
Hors Sujet mais
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 () le 21/04/2004 à 09:00. (lien). Évalué à 1.T'aurais pu nous épargner le long troll ;-)
http://linuxfr.org/comments/393526.html(...)
Re: Qt 4 à l'horizon !
Paru sur la mailing list Qt :
«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 () le 21/04/2004 à 10:07. (lien). Évalué à 1."but fewer than 30 seats remain"
ben il semble que non ....
-
[^]Re: Qt 4 à l'horizon !
Posté par Guillaume Laurent (page perso, ) le 21/04/2004 à 22:53. (lien). Évalué à 2.Tu sais combien coute l'entrée dans ce genre de meeting en général ? Un truc comme Java One par exemple :
http://javaone.medialiveinternational.com/sf2004/registration.html(...)
-
[^]Re: Qt 4 à l'horizon !
Posté par Erwan (page perso, ) le 22/04/2004 à 05:17. (lien). Évalué à 2.Le « only $100 » a juste eu un peu de mal à passer...
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 !
(hors sujet)
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 (page perso, ) le 21/04/2004 à 08:30. (lien). Évalué à 3.sur le site de GnomeMeeting:
...Update: It was of course the traditional 1st April Fool!...
-
[^]Re: Qt 4 à l'horizon !
Re: Qt 4 à l'horizon !
J'ai une autre question.
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 () le 21/04/2004 à 09:41. (lien). Évalué à 1.Il faut que le desktop soit homegene et cohérent, sinon ça fait bricolo et
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 !
-
[^]Re: Qt 4 à l'horizon !
Posté par wismerhill (page perso, ) le 21/04/2004 à 10:15. (lien). Évalué à 2.C'est idiot de se passer de toutes les appli non KDE sous prétexte qu'on utilise KDE.
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 () le 21/04/2004 à 11:55. (lien). Évalué à 0.>> Et je connais beaucoup de personnes qui utilisent k3b sous gnome (et pourtant utiliser >>les appli KDE hors de KDE est assez lourd).
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 (page perso, ) le 21/04/2004 à 13:35. (lien). Évalué à 2.Non, c'est seulement au premier programme KDE que c'est lourd parce qu'il faut aussi démarrer DCOP et d'autres services KDE. Pour les suivants ça tourne déjà.
-
-
-
[^]Re: Qt 4 à l'horizon !
Posté par gnumdk (page perso, ) le 21/04/2004 à 12:46. (lien). Évalué à 3."J'ai l'impression que la demande de merge vient essentiellement des gens qui utilisent Gnome."
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.--
Agogo-
[^]Re: Qt 4 à l'horizon !
-
-
[^]Re: Qt 4 à l'horizon !
Posté par yoplait () le 21/04/2004 à 15:16. (lien). Évalué à 2.J'ai l'impression que la demande de merge vient essentiellement des gens qui utilisent Gnome. Enfin bon.
Tiens c'est bizarre. J'avais plutot l'impression du contraire. :)-
[^]Re: Qt 4 à l'horizon !
Posté par Pierre Jarillon (page perso, ) le 23/04/2004 à 00:32. (lien). Évalué à 2.Mais non, on t'as dit plus haut que c'était le contraire !
(ça c'est du troll de premier choix ;-))
-
-
Cette page a été générée par Templeet en 0.3203s (dont 0.0607 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
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.