Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de bersace :
- [18/03@02:28] Beryl/Compiz sur iMac G5 rev C [vidéo]
- [20/02@15:21] Prématurée à 22 semaines
- [03/02@20:08] Carte clavier mac fr
- [20/01@03:19] Novell vous propose de passer à Linux sans passer par la case Vista
- [12/01@20:02] Vite vite, un troll !
- [11/01@19:43] Ubuntu — Vu à la télé !
- [19/12@18:41] Gnome Scan 0.4 : « Votre logiciel est-il people-ready™®© ? »
- [11/12@16:15] RIAA: heureusement que le ridicule ne tue pas !
- [06/12@12:47] Enfin Ubuntu Herd 1
- [04/12@13:31] Support des namespace dans PHP
- [29/11@19:47] J'ai testé: Vista sur Macbook
- [20/11@17:09] Colloque à l'assemblée nationale : Politiquement Internet
- [24/10@17:20] Colloque sur les NTIC post DADVSI
- [18/10@20:49] En vue d'Ubuntu 7.04
- [16/10@19:27] Gnome Scan 0.3 : La numérisation pour la masse
- [13/10@09:48] Pétition GMail IMAP
- [27/09@09:43] Windows® ? le meilleur alibi de la migrer !
- [21/08@16:54] gnomescan-0.2: greffon Gimp, i18n, PDF et plein de bonnes choses !
- [12/08@01:57] gnomescan-0.1
- [26/06@17:56] Un artiste en chef pour Ubuntu
Journal : Un langage pas comme les autres : Vala
Posté par Étienne Bersac (Jabber id, page perso, ) le 23 mars 2007Une recherche sur linuxfr pour le terme "vala" met bien en valeur la pauvreté de l'orthographe des linuxèfèriens. En effet c'est à chaque fois une orthographe douteuse du mot "voilà" qui est recensé.
Pourtant, à propose de langue, Vala est un vrai langage ! Un vrai langage, mais un langage pas comme les autres. Son but est simple et paraît pas franchement novateur au premier coup d'½il :
Vala veut donner au développeur Gnome les fonctionnalités de langages modernes sans ajouter de nouvelle dépendance à l'exécution, ni utilise une ABI différente de celle des logiciels et bibliothèque écrite en C.
Concrètement, Vala traduit un synthaxe proche du C# directement en C/GObject. La syntaxe est adaptés au spécificité du système de typage de GObject (signaux, greffons, etc.). Ou comment inventer un langage sans en créer un autre ;).
Comment utiliser une bibliothèque en C dans du Vala ? Pas besoin de passerelle à l'exécution, il suffit de fournit un définition d'API à vala pour qu'il fasse la traduction, au final, c'est toujours du C. Il existe déjà un outils vapigen qui génère automatiquement un définition d'API à partir de bibliothèque GObject. Cet outils est basé sur un outils similaire du projet Mono.
Je trouve ce langage franchement révolutionnaire pour Gnome ! C'est un fait reconnu que le C/GObject est fastidieux, mais rien de garantie mieux performance et ouverture vers les autres langages. Il n'y a même pas besoin de définir Vala comme un langage accepté dans Gnome, puisque c'est du C !
Le projet est encore à un état instable, mais on peut déjà écrire un "Salutations"¹ en Gtk+ ! La version 0.0.7 contient pas mal de test (29) qui permette de voir l'évolution du support du langage.
Courrez vite visiter http://live.gnome.org/Vala !
Étienne.
¹. J'utilise "Salutations" pour traduire "Hello world!", c'est mon choix©®™.
> Lire le journal (104 commentaires, moyenne: 2,6).
La différence
Un bon moyen de voir l'utilité de vala, c'est de prendre un .vala fournit sur le wiki et de le traduire en C avec valac --pkg gtk+-2.0 *.c. La différence en nombre d'octets tes pharamineuses ! Et le code C est propre !
Étienne.
E Ultreïa !
-
[^]Re: La différence
Posté par Snark_Boojum () le 23/03/2007 à 17:24. (lien). Évalué à 2.Genre comme le deuxième exemple où un signal foo est défini, et où une lambda expression foo est définie ?
...
Many developers want to write GNOME applications and libraries in high-level programming languages but can't or don't want to use C# or Java for various reasons, so they are stuck with C without syntax support for the GObject type system.
Et le python, ruby , (C++) ils sont ou ?
-
[^]Re: ...
Posté par Étienne Bersac (Jabber id, page perso, ) le 23/03/2007 à 18:44. (lien). Évalué à 1.Essaie de faire une bibliothèque aussi performante dans ces langages, essaie de faire une passerelle ruby->python, :).
La règle pour être intégré dans la plateform de Gnome, c'est d'être en C/GObject. Après, il y a les passerelles.
Étienne.--
E Ultreïa !-
[^]Re: ...
Posté par Matthieu C () le 23/03/2007 à 19:16. (lien). Évalué à 2.Essaie de faire une bibliothèque aussi performante dans ces langages,
Je croyais que le pb, ct que les bibliothèque était en C mais que les applis voulais des language de haut niveau.
Et puis C et performance, ca veut rien dire : si on ajoute une couche haut niveau (exception, garbage collector, ...) et ben ca a un cout.
essaie de faire une passerelle ruby->python, :).
Pourquoi faire du ruby->python ?
GTK c'est du C et je proposais des applis en python/ruby.
J'ai jamais essayé de faire de telle passerelle, mais j'ai déja vu plusieurs passerelle python/ruby -> C.
PS : j'ose meme pas imaginer débugger des programmes ecrit en vala (en tout cas avec le backend C de gdb)...
PS2 : qd on voit le succes objective C (en openstep), j'espere qu'il aura plus de succes.-
[^]Re: ...
Posté par Étienne Bersac (Jabber id, page perso, ) le 23/03/2007 à 19:36. (lien). Évalué à 2.> Et puis C et performance, ca veut rien dire : si on ajoute une couche haut niveau (exception, garbage collector, ...) et ben ca a un cout.
Au moins, la surcouche est à la compilation, pas à l'exécution. Et le système de typage GObject est largement plus performant que ce qu'on trouve en Java, Python, C# etc. Rien que par le fait de mixer les types natifs (avec gint, gchar, gpointer, gboolean) et les types "haut niveau" (G_TYPE_OBJECT, G_TYPE_INTERFACE et leurs enfants).
Cordialement,
Étienne.--
E Ultreïa !-
[^]Re: ...
Posté par Matthieu C () le 24/03/2007 à 13:06. (lien). Évalué à 5.Au moins, la surcouche est à la compilation, pas à l'exécution.
A bon, parce que les fonctions de la glib on les appele pas ou parce qu'elle ne font rien ?
Et le système de typage GObject est largement plus performant que ce qu'on trouve en Java, Python, C# etc.
Un bench serait le bienvenu.
Un langage de plus haut niveau peut etre plus performant que du C sur des trucs de haut niveau parce que le developeur se concentre sur ce qu'il veut faire, le language (et le framework) se charge de choisir ce qui se fait de mieux (algo optimisé choisi dynamiquement en fonction de l'entrée) et eviter au developpeur d'avoir a reinventer la roue pour interfacer les différents composants (qui d'ailleurs si c'est mal fait peu etre catastrophique au niveau perf ou au niveau evolutivité).
Dire que le C est plus rapide que les langages haut niveau, c'est aussi stupide que dire que l'assembleur est plus rapide que le C :
C'est vrai si t'as des developpeurs qui sont des génies, qui connaisent toute les optimisations possibles, qui on du temps devant eux.
C'est rarement le cas dans la realité.
(Je ne crache pas sur le C, mais chaque langage a ses propriétés et ses applications).
PS: je comprend parfaitement que la majeur partie de gnome est écrite en C, et qu'ils doivent faire avec. vala peut etre une solution, mais je la considere plus comme une rustine, qu'un truc revolutionnaire.-
[^]Re: ...
Posté par Gniarf () le 24/03/2007 à 15:54. (lien). Évalué à 3.Un langage de plus haut niveau peut etre plus performant que du C sur des trucs de haut niveau parce que le developeur se concentre sur ce qu'il veut faire(...)
ah non, là tu confonds les capacités du développeur et celles du langage...--
Windows has no users. It has hostages.-
[^]Re: ...
Posté par Thomas Douillard () le 25/03/2007 à 12:57. (lien). Évalué à 7.Héhé, avec un raisonnement pareil, il n'y a que les idiots qui ne coderaient pas en assembleur parce qu'il sont trop stupide pour ça, et pas parce que c'est une perte de temps de lire et d'écrire des "jump label" au lieux de faire du polymorphisme. Tu sais le "je réfléchis plus à mon algorithme et à mon modèle qu'à mon code" ...
Sérieusement, tu auras beau être super doué, c'est plutôt agréable de se reposer sur un langage haut niveau pour implémenter un algo proche de ce qu'on a imaginer que de pisser de la ligne au kilomètre pour faire la même chose ... et plus rapide. Ce qui laisse du temps pour faire autre chose.
Le tout à compétence du développeur égale. Alors, l'expressivité (l'efficacité on va dire) du langage n'a vraiment aucune importance ?-
[^]Re: ...
Posté par Gniarf () le 25/03/2007 à 21:44. (lien). Évalué à 2.> tu confonds les capacités du développeur et celles du langage
avec un raisonnement pareil, (...)
de quel raisonnement tu parles ?
Alors, l'expressivité (l'efficacité on va dire) du langage n'a vraiment aucune importance ?
j'ai dit ça ? non-non. et puis tu négliges des tas de paramètres comme la disponibilité et la maturité de ces fameux "langages haut niveau" et de tout ce qui va avec, bibliothèques, outils complémentaires, méthodes, sans même parler d'éventuels problèmes de licence.--
Windows has no users. It has hostages.
-
-
-
[^]Re: ...
Posté par Yusei () le 25/03/2007 à 09:51. (lien). Évalué à 8.Un langage de plus haut niveau peut etre plus performant que du C sur des trucs de haut niveau parce que le developeur se concentre sur ce qu'il veut faire, le language (et le framework) se charge de choisir ce qui se fait de mieux
Hum, non, un langage de haut niveau peut être plus performant que du C parce que le compilateur dispose d'informations de plus haut niveau qui peuvent lui permettre de faire de meilleurs choix qu'un compilateur C qui a une vision plus limitée du programme.
Par exemple en utilisant GObject pour faire de l'objet en C, on a des pointeurs de fonction dans tous les sens. Le C++ peut être plus efficace rien qu'en décidant d'inliner certaines fonctions quand c'est possible (recopier le code au lieu de faire des appels de fonction).
Le problème peut toujours théoriquement être contourné par le programmeur qui peut faire des choix "de haut niveau" à la place du compilateur, mais il est inenvisageable que ce soit le programmeur qui transcrive un concept de haut niveau comme l'héritage entre ses classes en code de bas niveau. Sur un petit programme c'est faisable, mais totalement impossible à maintenir après. D'où le fait que, même quand on code en C, on fait des compromis entre rapidité d'exécution et temps de développement, et on se retrouve avec du code générique plus lent que l'optimum.
-
[^]Re: ...
Posté par Mildred (Jabber id, page perso, ) le 27/03/2007 à 11:32. (lien). Évalué à 3.L'avantage du C est aussi d'être compatible avec beaucoup d'autres langages. Avec le C++ ce n'est plus forcément si évident.
-
-
-
-
Performances
>>> C'est un fait reconnu que le C/GObject est fastidieux, mais rien de garantie mieux performance et ouverture vers les autres langages
Si le C est la garantie de bonnes performances alors pourquoi Nautilus est-il si misérablement lent ? Pourquoi Gnome est, d'une manière générale, assez lourd à l'utilisation ?
PS : c'est un gnomiste convaincu qui pose la question.
-
[^]Re: Performances
Posté par Étienne Bersac (Jabber id, page perso, ) le 23/03/2007 à 19:32. (lien). Évalué à 1.Salut,
Bonne question. C ne veut pas dire optimisé. Mais nautilus en ruby, j'ose pas imaginer ;).
> pourquoi Nautilus est-il si misérablement lent
Gnome-VFS est super lent et foireux. Sinon, en local je trouve pas nautilus si lent.
> Pourquoi Gnome est, d'une manière générale ?
Un bout de réponse : les perfs de cairo (cf dépêche 1.4), le bugs d'optimisation, etc.
Ni Gnome, ni C ne sont parfait ! Mais j'ose pas imaginé Gnome si Gtk était écrit en ruby, cairo en C# et nautilus en C++ …
Étienne.--
E Ultreïa !-
[^]Re: Performances
Posté par Thomas Douillard () le 24/03/2007 à 12:01. (lien). Évalué à 2.Peut être que gnome-vfs serait moins foireux, que les devs auraient eu plus de facilité à optimiser Cairo et que le bug d'optimisation ne serait pas apparu ?
Parce que les dev auraient eu moins besoin de se concentrer sur l'utilisation de trucs bas niveaux pour faire en réalité plutôt des trucs (en général) hauts niveaux ...-
[^]Re: Performances
Posté par Étienne Bersac (Jabber id, page perso, ) le 24/03/2007 à 18:26. (lien). Évalué à 1.gnome-vfs est pas franchement une techno apprécié de gnome. Cf. vio sur freedesktop. http://lists.freedesktop.org/archives/xdg/2007-January/00914(...)
--
E Ultreïa !-
[^]Re: Performances
Posté par Thomas Douillard () le 24/03/2007 à 18:41. (lien). Évalué à 2.Héhé, encore une preuve que le C c'est la panacée pour implémenter une techno ^^
Le prends pas mal, mais j'ai un peu l'impression que tu réponds à côté, là, le propos c'était :
>>gnome vfs est lent, d'autres trucs sont foireux
> c'est peut être à cause du C
gnome-vfs est pas très apprécié ...
Ben justement, peut être que si gnome avait été pensé plus haut niveau et pas pour être implémenté en C, peut être qu'il serait plus apprécié.
(bon ok, j'ai pas beaucoup d'argument, mais toi t'en es aussi au degré zéro de l'argumentation ... qui à dit "troll" ? )
-
-
-
-
[^]Re: Performances
Posté par IsNotGood () le 23/03/2007 à 20:23. (lien). Évalué à 4.Parce que le C c'est nul et les développeurs Gnome sont des cons.
T'as une autre explication ?-
[^]Re: Performances
Posté par patrick_g (page perso, ) le 24/03/2007 à 06:50. (lien). Évalué à 10.Je sais que le but dans la vie ce n'est pas de se faire à tout prix des copains mais est-ce que tu pourrais, au minimum, arrêter d'employer perpétuellement un ton méprisant envers les autres ?
Je suis un libriste mais je suis aussi un mec rationnel qui garde les yeux ouverts. Je sais faire un comparatif à la louche entre deux logiciels...ça tombe bien car j'utilise Ubuntu chez moi et XP au boulot.
Comparons l'ouverture de deux gros répertoires.
1) Si j'essaye d'ouvrir avec l'explorateur Windows le dossier system\win32 sur le portable du travail (DD 5400rpm) cela prend environ 3s pour avoir l'affichage.
2) Si j'essaye d'ouvrir avec Nautilus le dossier /usr/bin sur le portable de la maison (DD 5400rpm) cela prend environ 74s pour avoir l'affichage !!!!!
Ceci ne me gène pas énormément car je ne vais pas souvent visiter d'énormes dossiers comme /usr/bin mais cela démontre qu'il y a un gros problème avec Nautilus.-
[^]Re: Performances
Posté par Gregory Auzanneau (page perso, ) le 24/03/2007 à 07:32. (lien). Évalué à 1.Pour la défense de Nautilus, on peut tout de même préciser, à l'inverse de l'explorer de Windows, qu'il analyse tous les fichiers du répertoire afin de pouvoir déterminer le type et t'afficher une belle icône (executable, perl, une miniature de l'img, etc etc).
Pour avoir une idée, ça prend combien de temps pour l'explorateur de KDE d'afficher /usr/bin ?-
[^]Re: Performances
Posté par blobmaster () le 24/03/2007 à 08:35. (lien). Évalué à 1.>> Pour avoir une idée, ça prend combien de temps pour l'explorateur de KDE d'afficher /usr/bin ?
C'est si rapide que j'ai pas trop compté mais je dirais autour d'une seconde en tout cas moins de deux.
Et ce quel que soit le mode d'affichage (il y en a une dizaine).
(Machine achetée en Octobre et puissante)-
[^]Re: Performances
Posté par elloco (page perso, ) le 24/03/2007 à 08:52. (lien). Évalué à 1.Pour moi, sur une machine plus très récente mais pas mauvaise quand même, KDE prend 8 à 9 secondes pour afficher 2300 fichiers.
Et si je le rouvre directement après, 0 secondes (il est donc dans le cache)
-
-
[^]Re: Performances
Posté par koxinga () le 24/03/2007 à 09:55. (lien). Évalué à 2.Et si on ne veut pas qu'il analyse tout cela, il y a moyen de le désactiver ?
-
[^]Re: Performances
-
-
[^]Re: Performances
Posté par patrick_g (page perso, ) le 24/03/2007 à 12:03. (lien). Évalué à 4.>>> Pour la défense de Nautilus
On parle quand même d'un temps d'ouverture de répertoire multiplié par vingt-cinq !!!
Je comprends pas que les devs de Gnome ne se penchent pas sur ce problème.-
[^]Re: Performances
Posté par liberforce (Jabber id, page perso, ) le 26/03/2007 à 11:32. (lien). Évalué à 2.En fait ils se sont penchés dessus, j'avais produit des tests de performance à ce sujet lors d'un "gnome love performance day" il y a un an, car le problème m'énervait également..
http://bugzilla.gnome.org/show_bug.cgi?id=320282
Depuis peu de choses ont changé on dirait, malheureusement. Je viens de demander des infos à ce sujet. Peut être peux tu reproduire mes tests sur ta machine, qui a un disque dur assez lent. Cela permettra peut être plus en évidence les accès I/O. Faire une trace avec sysprof est très facile (vraiment !). Contacte moi à liberforce at fr point st pour plus d'infos.
-
-
-
[+] [^]Re: Performances
Posté par IsNotGood () le 24/03/2007 à 20:25. (lien). Évalué à -5.> Je sais que le but dans la vie ce n'est pas de se faire à tout prix des copains mais est-ce que tu pourrais, au minimum, arrêter d'employer perpétuellement un ton méprisant envers les autres ?
Car tu n'as pas été méprisant envers Gnome ? En lançant un troll à deux sous ?
> XP au boulot.
> ...
> 1) Si j'essaye d'ouvrir avec l'explorateur Windows
T'es au boulot le samedi matin ?
> cela démontre qu'il y a un gros problème avec Nautilus.
Ça ne serait pas encore du mépris ?
Je connais mal windows et je n'utilise pas Nautilus.
Mais sous Windows les icônes sans dans le programme. Sous Gnome ce n'est pas le cas.
Sous windows pour le type du fichier, c'est l'extension qui est utilisé.
Sous GNU/Linux, ça passe par magic(5).
Autre chose, il y a beaucoup plus de fichier dans /usr/bin/ que dans system/win32.
Et que disais-tu ?
> Nautilus est-il si misérablement lent
Misérablement lent !
Ce n'est pas du mépris ça encore ?
Mon /usr/bin/ qui est light a 1330 fichier. Ça prend 73 secondes selon toi, soit 18 fichiers par seconde. C'est ça misérablement lent ?
> mais cela démontre qu'il y a un gros problème avec Nautilus.
Fais un patch. (ton intentionnellement méprisant).-
[^]Re: Performances
Posté par patrick_g (page perso, ) le 24/03/2007 à 20:50. (lien). Évalué à 5.>>> Car tu n'as pas été méprisant envers Gnome ? En lançant un troll à deux sous ?
En quoi est-ce méprisant que de signaler le fait que Nautilus est incroyablement lent quand on tente d'ouvrir /usr/bin ?
En non ce n'est pas du mépris (venant de toi cette accusation serait presque drôle), c'est juste la constatation d'un fait.
Si tu est content du fait qu'un processeur cadencé à 1,86 milliards d'instructions par seconde ne puisse afficher que 18 fichiers par seconde libre à toi. Pour ma part je constate que ce n'est pas le cas des autres explorateurs de fichiers (Konqueror ou l'explorateur Windows ou Dolphin que je viens d'essayer et qui affiche ce répertoire en 1s environ).
>>> T'es au boulot le samedi matin ?
En quoi ça te regarde ?
T'a envisagé le fait que j'avais procédé à ce test avant d'écrire ce post dans ce journal ?-
[^]Re: Performances
Posté par IsNotGood () le 24/03/2007 à 21:00. (lien). Évalué à 0.> T'a envisagé le fait que j'avais procédé à ce test avant d'écrire ce post dans ce journal ?
Oui.
> Si tu est content du fait qu'un processeur cadencé à 1,86 milliards d'instructions par seconde ne puisse afficher que 18 fichiers par seconde libre à toi.
Pour ton info, le problème (s'il y a) n'a rien à voir avec Nautilus :
$ time file /usr/bin/*
real 1m7.625s
user 0m0.360s
sys 0m0.350s
T'as combien de fichier dans /usr/bin ?
Et tu disais quoi de Nautilus. Je vais te raffraichir la mémoire :
- "Nautilus est-il si misérablement lent"
- "cela démontre qu'il y a un gros problème avec Nautilus"
Tes affirmations ne tiennent sur rien.
> Si tu est content du fait qu'un processeur cadencé à 1,86 milliards
Et le temps d'accès à un fichier, ça prend combien de temps ? 10 ms au très très très minimum si les infos ne sont pas en cache. Soit au grand grand mieux 100 / s. Nautilus fait 18 /s c'est très bien. C'est n'est pas misérablement lent.-
[^]Re: Performances
Posté par Matthieu C () le 24/03/2007 à 22:25. (lien). Évalué à 6.Pour ton info, le problème (s'il y a) n'a rien à voir avec Nautilus :
$ time file /usr/bin/*
real 1m7.625s
user 0m0.360s
sys 0m0.350s
Ben si, c'est Nautilus qui a choisi d'utiliser cette méthode (lente) qui n'est pas forcement adapter a ce que veut l'utilisateur (qui d'ailleur se fou du moyen utilisé).
Et le temps d'accès à un fichier, ça prend combien de temps ? 10 ms au très très très minimum si les infos ne sont pas en cache.
Ben essaye avec d'autres programe (comme readelf -h) et tu veras...
Je ne parle meme pas de programme qui essayerais de faire des lecture asynchrone...-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 09:41. (lien). Évalué à 2.> Ben si, c'est Nautilus qui a choisi d'utiliser cette méthode (lente)
C'est Unix qui a choisi cette méthode et elle est très bien.
> qui n'est pas forcement adapter a ce que veut l'utilisateur
l'utilisateur veut plus de 18 fichiers par seconde ?
Le problème n'est pas là. Il faudrait par exemple que nautilus mette à jours la fenêtre au fur et à mesure qu'il collecte des infos.
> Ben essaye avec d'autres programe (comme readelf -h) et tu veras...
Dans l'exemple précédent, file faisant l'affichage dans une xterm. Ce qui ralentit significativement file.
Après avoir vidé le cache :
$ time (readelf -h * > /dev/null 2>&1 )
real 0m21.763s
user 0m0.150s
sys 0m0.210s
Après avoir vidé le cache :
time (file * > /dev/null 2>&1 )
real 0m20.324s
user 0m0.360s
sys 0m0.360s
Cache plein :
$ time (readelf -h * > /dev/null 2>&1 )
real 0m0.287s
user 0m0.190s
sys 0m0.080s
Cache plein :
$ time (file * > /dev/null 2>&1 )
real 0m0.714s
user 0m0.410s
sys 0m0.250s
Et car tout ça commence à me casser les couilles, j'ai installé Nautilus.
Pour Nautilus si le cache est vidé j'ai 22 secondes, et si le cache est plein moins de 2 secondes.
Donc tout va absolument bien avec Nautilus et readelf n'est pas plus rapide que file ou Nautilus.-
[^]Re: Performances
-
-
-
[^]Re: Performances
Posté par fmaz fmaz () le 25/03/2007 à 09:26. (lien). Évalué à 4.Le coup du time, c'est ridicule.
C'est clair qu'analyser 10000000000 de fichiers, ça prend du temps. Mais Nautilus n'affiche JAMAIS tous les fichiers en même temps. Donc techniquement, pour afficher la fenêtre, il lui suffit d'analyser les fichiers dont il va afficher les icones et c'est tout. Ensuite, s'il en a besoin, il peut analyser les autres fichiers.-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 09:56. (lien). Évalué à 2.> Mais Nautilus n'affiche JAMAIS tous les fichiers en même temps.
Très juste. C'est ici qu'il faut travailler la question mais c'est loins d'être évident. Comme savoir ce qui doit être affiché avant d'avoir correcté les infos ?
C'est réalisable dans le mode liste. Chaque fichier occupe la même place dans la fenêtre. Donc si la scoll barre est à 54 % par exemple, on connait les fichiers qu'il faut examiné. Dans les autres modes, on ne sait pas.-
[^]Re: Performances
-
[^]Re: Performances
Posté par ola () le 26/03/2007 à 14:45. (lien). Évalué à 0.Dans les autres modes, on ne sait pas.
ouch.
si c'est reellement le cas, ya la tete d'un designer d'IHM qui devrait tomber...
'fin ce que j'en dit, un soft de ce genre qui n'est pas capable de faire une correspondance vue/modele, ya un ENORME probleme dans l'equipe..
-
-
-
-
[+] [^]Re: Performances
Posté par IsNotGood () le 24/03/2007 à 21:03. (lien). Évalué à -2.> qui affiche ce répertoire en 1s environ
Doit faire avec le "Windows touch" (c'est-à-dire n'utilise pas magic(5)). Si tu préfères Windows, prends Windows.-
[^]Re: Performances
Posté par patrick_g (page perso, ) le 25/03/2007 à 06:40. (lien). Évalué à 7.>>> Si tu préfères Windows, prends Windows.
Je te jure c'est vraiment pénible ta mauvaise foi à toute épreuve.
Est-ce que tu peux comprendre qu'il y a bien un problème spécifique à Nautilus mais que cela n'implique pas le moins du monde que je crache sur les devs de Gnome ?
Je signale le problème c'est tout.
Alors reprenons :
Machine : Laptop Pentium M 1.86 GHz avec DD 5400 rpm
OS : Ubuntu 6.10 Edgy
Répertoire de test pour l'affichage : /usr/bin (1455 éléments)
Test d'ouverture de ce répertoire (affichage en mode détails pour tous les logiciels) :
Konqueror (version 3.5.5) => Temps d'ouverture : 1s pour l'affichage (env 10s pour que les icones spécifiques des fichiers finissent d'apparaitre).
Dolphin (version 0.6.0) => Temps d'ouverture : 1s
Thunar (version 0.4.1) => Temps d'ouverture : 21s
Nautilus (version 2.16.1) => Temps d'ouverture : 76s
Commentaires :
* Dolphin est Thunar sont des logiciels non matures et en développement rapide. Pour bien faire j'aurai du utiliser les version SVN et non les paquets de ma distro qui sont déjà anciens (Thunar est actuellement en version 0.8 et Dolphin en version 0.8.2).
* Tous ces logiciels affichent des icônes spécifiques selon le type de fichier sauf dolphin qui se contente d'afficher une icône standard.
* Le problème de lenteur à l'affichage vient peut-être de GTK+ car Thunar a un temps d'ouverture assez long (mais comme c'est une version de dev très dépassée je ne connais pas la performance du Thunar actuel).
* Nautilus a clairement un gros problème avec l'affichage des répertoires contenant beaucoup de fichiers. C'est d'autant plus grave qu'il est sensé être un logiciel mature à la différence de Dolphin ou Thunar.
Screenshots des différents logiciels :
Konqueror : http://www.flickr.com/photo_zoom.gne?id=433244344&size=o
Dolphin : http://www.flickr.com/photo_zoom.gne?id=433244342&size=o
Thunar : http://www.flickr.com/photo_zoom.gne?id=433244350&size=o
Nautilus : http://www.flickr.com/photo_zoom.gne?id=433244348&size=o
Conclusion :
Est-ce que maintenant IsNotGood pourrait daigner accepter mon constat d'un problème existant dans Nautilus et cesser de crier au troll ?-
[+] [^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 09:47. (lien). Évalué à -4.> Nautilus a clairement un gros problème avec l'affichage des répertoires
Pour les icons, Nautilus utilise SVG et c'est TRÈS BIEN. KDE 4 qui utilise SVG dit que ça impacte les performances. KDE 4 aura peut-être SVG, on va voir s'il est aussi rapide que Nautilus (ou selon ta terminologie aussi buggué que Nautilus).
Tu n'as avancé aucune évidence d'un gros problème ou bug alors que tu n'arrêtes pas de l'affirmer. Désolé si je suis méprisant, mais c'est tout ce que ton commentaire m'inspire.-
[^]Re: Performances
Posté par patrick_g (page perso, ) le 25/03/2007 à 11:56. (lien). Évalué à 6.>>> Tu n'as avancé aucune évidence d'un gros problème ou bug alors que tu n'arrêtes pas de l'affirmer.
Je me casse le cul à te démontrer que Nautilus met 76 putains de secondes à afficher un répertoire et toi tu continue à puer de mauvaise foi et à ne rien faire d'autre qu'écrire et cracher sur les autres.
T'a fait quoi te ton coté pour constater ce problème ?
Pour toi ce n'est pas un gros problème que de voir tourner la petite animation d'attente pendant largement plus d'une minute alors que les explorateurs sous QT mettent une seconde ?
J'arrête là ce thread. On ne peux pas discuter avec un mec comme toi.-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 12:30. (lien). Évalué à 0.> toi tu continue à puer de mauvaise foi
J'ai dit que Nautilus était aussi rapide que le truc sous Windows ?
Non.
Toi tu affirmes qu'il y a un bug ou un gros problème Nautilus sans la moindre preuve.
Si tu veux dire que le mécanisme magic(5) est plus lent que d'utiliser les saloperies d'extension du nom de fichier, pas de problème, je suis d'accord, je l'ai déjà dit.
Mais sous Nautilus si je renomme "titi.jpg" en "titi.jpg.old", ça reste un fichier jpg et considéré comme tel. Si je renomme "titi.jpg" en "titi.exe" sous Nautilus ça ne se transforme pas en un programme. Sous Windows tu changes le type en changant son noom. C'est une aberration. Un fichier jpeg devient un fichier texte ou je ne sais quoi si tu le renomme *.jpg.old. Si tu double-cliques dessus Windows va lancer notepad ou je ne sais quoi mais un truc inadapté.
C'est n'est pas un gros problème ça ?
Autre truc. Sous Unix/Linux, les exécutable n'ont pas d'extension. Comme tu fais pour savoir si c'est un exécutable ? Car il n'y a pas d'extension ? C'est insuffisant. Il y a plein de fichier texte sous Unix/Linux sans extension par exemple (README, INSTALL, FAQ, NEW, etc...).
Autre problème. Il y a des fichiers avec les mêmes extensions mais qui ne sont pas du même type. Comme tu fais avec Windows ? Ben Windows affiche une boîte de dialogue pour choiser le programme qui va. Sous Nautilus ce n'est pas le cas.
Magic(5) n'est pas un problème ou un bug, magic(5) est la solution pour Unix.
Nautilus utilise ce qui est adapté pour Unix et ce n'est pas de la faute à Nautilus, ce n'est pas un gros bug Nautilus. Et te n'a en rien démontré le contraire.
Tu m'insultes de mauvaise fois (m'enfin c'est à la mode avec moi quand il n'y a plus d'argument), mais toi que fais tu ?
Tu fais des affirmations, des accusations de gros problèmes ou bugs, et ce sans la moindre preuve, sans le moindre semblant de réflexion.
> Pour toi ce n'est pas un gros problème
Je n'ai jamais dit que la lenteur de magic(5) n'était pas un problème. Quelqu'un propose une solution dans le cas de Nautilus (n'examiner que les fichiers affichés et je l'appuis à 100%). Par contre je dis et je répète que Nautilus n'a pas de gros problèmes ou bugs.
La solution de Windows a aussi des gros problèmes. Tu n'aurais pas remarqué ?
Par exemple sous Windows le type du fichier est dans le nom du fichier. Le concept est si pourri que par défaut Windows ne permet pas de changer tout le nom du fichier. Je dis que ce concept est pourri, je ne dis pas que le file manager de Windows (ou dauphin, etc...) a un bug.
> Nautilus met 76 putains de secondes à afficher un répertoire
Et dans quelles conditions ? Car tu va ouvrir /usr/bin que la majorité des gens ne vont pas ouvrir. Pour lancé un programme, c'est le menu gnome qu'il faut utiliser et qui est utilisé dans 99,9 % des cas.
Vu le temps que ça te prend, il doit y avoir 2000 fichiers dans ton /usr/bin. Es-ce un cas classique d'utilisation d'un file manager ? Les files manager sont pour $HOME à 99 %. Les cas où on va snifer /usr/bin, c'est dans 99 % des cas pour troller sur Nautilus.
> alors que les explorateurs sous QT mettent une seconde ?
Ce qui n'a rien à voir avec le toolkit graphique.
Je te laisse à tes trolls.-
[^]Re: Performances
Posté par benja () le 25/03/2007 à 21:37. (lien). Évalué à 5.J'ai fait le test chez moi avec un nautilus 2.14.3 (debian unstable) et il met bien plus de 30 sec pour afficher la première icone d'un /usr/bin de 2581 fichiers (sur un ibook G4/1GHz). Utiliser la complétition automatique du file-chooser dans /usr/bin est inutilisable. Même si l'intérêt est quasi nul dans ce cas, je peux facilement imaginer quelqu'un possédant un répertoire contenant plus de mille fichiers.
Alors que faire un magic sur les fichiers soit lent, c'est compréhensible. Mais ce n'est pas une raison pour ne pas savoir le faire de façon asynchrone. Nautilus devrait pouvoir afficher plus rapidement le contenu de la fenêtre (24 icones dans mon cas, soit <1% du répertoire) et les redissiner au fur et à mesure que magic fasse son travaille (inutile aussi de "magicifier" les fichiers non-affichés).
Sur ce, on peut troller sur le fait que ce travaille d'optimisation n'a pas été fait parce qu'il serait plus difficile de retravailler cet algo dans un programme en C mais c'est une autre histoire...-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 21:56. (lien). Évalué à 1.> Nautilus devrait pouvoir afficher plus rapidement le contenu de la fenêtre (24 icones dans mon cas, soit <1% du répertoire) et les redissiner au fur et à mesure que magic fasse son travaille (inutile aussi de "magicifier" les fichiers non-affichés).
http://linuxfr.org/comments/815651.html#815651 (c'est de moi).
> Sur ce, on peut troller sur le fait que ce travaille d'optimisation n'a pas été fait parce qu'il serait plus difficile de retravailler cet algo dans un programme en C mais c'est une autre histoire...
Le C ça pue. Quel catastrophe que le C soit le language le plus utilisé dans le libre. Je n'ose imaginer comme le noyau Linux serait merveilleux s'il était codé avec un vrai language d'homme comme le C++.
Tous des tarlouse les développeurs noyaux.-
[^]Re: Performances
Posté par benja () le 25/03/2007 à 22:27. (lien). Évalué à 3.Merci de re-re-renter dans le troll (j'avais prévenu pourtant) :-)
Merci aussi de comparer des pommes et des poires (c'est sûr qu'un noyau et un toolkit ont les mêmes impératifs...).
Si tu veux, tu peux comparer GTK à FLTK qui est très bien, parait-il (je ne l'ai jamais utilisé, le c++ c'est beurk pour moi). Où alors linux v2.2 avec BeOS.
-
-
-
[^]Re: Performances
Posté par kadreg (page perso, ) le 26/03/2007 à 11:15. (lien). Évalué à 4.Bon, et si c'est alan cox qui dit qu'il y a une merde là dedans, au moins, lui tu le crois :
http://linuxfr.org/2001/08/26/4667.html
(putain, 2001, et rien a évolué. Je croyais que les logiciels libres avaient l'avantage de la réactivité ...)
-
-
-
-
[+] [^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 09:50. (lien). Évalué à -1.> Est-ce que maintenant IsNotGood pourrait daigner accepter mon constat d'un problème existant dans Nautilus et cesser de crier au troll ?
Non.
Et c'est toi qui troll.
Trouve un file manager qui utilise magic(5) (c'est bien) et SVG (c'est bien) qui va plus vite que Nautilus si tu veux arrêter de troller.-
[^]Re: Performances
Posté par Alex () le 26/03/2007 à 11:35. (lien). Évalué à 3.Le problème ne vient pas de l'utilisation de magic, mais de la façon dont l'affichage se fait : konqui par exemple prend énormément de temps à détecter le type de fichier et à génerer les thumbs des images, fichiers pdf, etc... (si ils ne sont pas déjà en cache bien sur). Néanmoins quand j'ouvre un répertoire, il m'affiche instatanément son contenu, et ensuite remplace petit à petit les icones par les thumbs, et ce en priorité pour les fichiers affichés dans ma fenêtre. Du coup ça parait quasi instantané, alors qu'au final il prend surement autant de temps que n'importe quel autre filemanager pour réaliser l'opération complète.
Donc moi je suis également assez daccord pour dire que pour un navigateur de fichier, c'est un gros problème.
-
-
[^]Re: Performances
Posté par pingui (Jabber id, ) le 25/03/2007 à 13:04. (lien). Évalué à 2.Juste pour donner le temps (en gros) chez moi avec Thunar 0.8: ça met environ 2sec.
Il y a une amélioration notable des temps d'ouverture avec cette version 0.8 (bon je n'ai pas vérifié si le cache était vide ou pas vu que j'avoue ne pas trop savoir vers où regarder), mais en tous cas ça ne prend plus 20sec comme avant.
-
-
-
-
-
-
-
[^]Re: Performances
Posté par sanao () le 23/03/2007 à 22:41. (lien). Évalué à 8.Mon Konqueror fonctionne vite. Il est surement écrit en C...
PS : Je demande l'indulgence, on est toujours vendredi.-
[^]Re: Performances
Posté par Étienne Bersac (Jabber id, page perso, ) le 24/03/2007 à 10:28. (lien). Évalué à 2.Je n'accuse pas le C++ de piètre performance, (y'a pas d'interprêteur ni de machine virtuelle). Parcontre, pour les passerelles vers d'autres langages, c'est pas au niveau de GObject.
Bref, C++ c'est (très) bien, mais àmha pas si on veut aussi coder en python, ruby, perl, avec la même bibliothèque.
Étienne--
E Ultreïa !-
[^]Re: Performances
Posté par CrEv (page perso, ) le 24/03/2007 à 10:53. (lien). Évalué à 4.enfin c'est surtout que coder en GObject ça pue donc tout le monde préfère coder les applis en python, ruby (ça c'est en langage qu'il est bien) ou perl
Mais quand on a gouté à qt, au model objet et surtout à la cohérence de l'ensemble ben y'a pas photo, ça marche bien, vite et ça se code assez facilement, que du bonheur (note : j'ai surtout touché à qt4, le 3 je connais moins)
-
[^]Re: Performances
Posté par golum () le 24/03/2007 à 11:25. (lien). Évalué à 2.Gtk et le langage C, c'est pas cette lib avec laquelle on simule l'héritage avec des cast de structure, cette lib avec laquelle on caste des void* pour simuler le polymorphisme, cette lib avec laquelle on ne dispose pas de l'héritage virtuel des opérations et avec laquelle les contrôles de types sont confiés aux programmeur.
Gtk c'est pas cette lib que l'on a wrappé avec Gtkmm pour pouvoir l'utiliser convenablement avec un vrai langage objet.
Bref une lib objet qui oblige les programmeurs à les implementer au lieu de s'appuyer sur un langage adapté.
Bon bah vaut mieux utiliser QT ou Fox alors
http://www.fox-toolkit.org/-
[^]Re: Performances
Posté par Yusei () le 25/03/2007 à 10:04. (lien). Évalué à 3.Gtk c'est pas cette lib que l'on a wrappé avec Gtkmm pour pouvoir l'utiliser convenablement avec un vrai langage objet.
Non, on l'a wrappée avec Gtkmm pour qu'on puisse l'utiliser avec C++. Pour l'utiliser avec de vrais langages, on l'a wrappée sur Ruby, Python, OCaml, Eiffel (un peu), ...
Et aussi sur Perl, PHP, Java, C#...
Et probablement Lisp, Ada, et tous les autres.
Bouh, que c'est mal, cette lib qu'on peut utiliser avec le langage de haut niveau de son choix. Y compris ceux qui te donnent de l'héritage, du vrai polymorphisme et qui contrôlent les types à ta place. C'est quand même très fort de réussir à présenter ça comme un défaut.-
[^]Re: Performances
-
[^]Re: Performances
Posté par golum () le 25/03/2007 à 11:03. (lien). Évalué à 1.C'est pas mal, c'est juste que c'est contre-productif.
Des wrapper pour Qt, tu en a dans tous les langages aussi (rubyqt, pyqt, Qt Jambi, ...)mais au moins ils ont utilisé un langage d'implémentation qui les supporte plutôt que de les réinventer.
Bref, utiliser un langage procédural pour faire de l'objet c'est à peu près aussi malin que d'utiliser un marteau pour enfoncer une vis.-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 12:34. (lien). Évalué à 1.> Bref, utiliser un langage procédural pour faire de l'objet c'est à peu près aussi malin que d'utiliser un marteau pour enfoncer une vis.
Le C++ est aussi traduit en procédural. Il n'y a pas de CPU qui font de l'objet.
Utiliser C++ c'est comme "utiliser un marteau pour enfoncer une vis" ?-
[^]Re: Performances
Posté par Thomas Douillard () le 25/03/2007 à 12:47. (lien). Évalué à 3.Personne ne code en "C++ traduit en procédural", c'est le compilo qui fait ça. Et quand tu codes en C++, tu ne te soucie pas de comment le compilo va faire son boulot.
Quand tu codes en C/Gobject, tu te soucie de "comment coder de l'objet en procédural"-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 12:57. (lien). Évalué à 1.> c'est le compilo qui fait ça.
C'est gobject qui fait ça.
> Et quand tu codes en C++, tu ne te soucie pas de comment le compilo va faire son boulot.
Quand tu codes en C++ avec gtkmm, tu ne te soucie pas de comment le compilo va faire son boulot et comment c'est linker avec gobject.
C'est mignon comme type de réflexion mais ça ne va pas loins. Un programme C++ utilise la libc (c'est du procédurale), un programme Qt utilise libx11 (c'est encore du procédurale), un autre va utiliser dbus, etc...
Les trucs 100 % C++ ça n'existe pas.-
[^]Re: Performances
Posté par Thomas Douillard () le 25/03/2007 à 16:19. (lien). Évalué à 2.C'est mignon comme type de réflexion mais ça ne va pas loins. Un programme C++ utilise la libc (c'est du procédurale), un programme Qt utilise libx11 (c'est encore du procédurale), un autre va utiliser dbus, etc...
Les trucs 100 % C++ ça n'existe pas.
Quand tu codes en C++, tu te fiches de la libc, quand tu codes en Qt, tu te fiches de la libx11. D'ailleurs QT n'utilise pas forcément la libx11, sous windows par exemple.
Les langages objets te permettent d'utiliser la POO sans te poser trop de question. Le C c'est déjà plus tendu, plus tricky pour implémenter de l'objet. Pourquoi vala sinon ?-
[^]Re: Performances
Posté par golum () le 25/03/2007 à 16:32. (lien). Évalué à 1.Il fait semblant de ne pas comprendre , je crois.
Je lui conseille la lecture de cet excellent livre pour comprendre en quoi le lange C n'est pas adapté pour la POO
http://www.planetpdf.com/developer/article.asp?ContentID=663(...)-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 17:00. (lien). Évalué à 1.> comprendre en quoi le lange C n'est pas adapté pour la POO
T'es gentil, je le sais. Je n'ai jamais dit de faire du C++ avec du C (t'as remarqué le quasi non sens de cette phrase ?).
Mais tu peux faire du java ou du python ou du C++ avec gtk+ qui est codé en C. Il y a des wrappers pour ça et ça marche bien.
C'est bien gentil de troller avec des "gtk c'est pas du C++" mais gtk a plein de wrappers qui marchent.
Le sénario où pour chaque fonctionnalités il faut la coder dans chaque language est une aberration (ça demande énormément de développeurs).
Il y a un wrapper de X11, libxml2, gstreamer, postgresql, etc pour C++ (par exemple Qt) et on trouve ça très bien. Et je trouve ça très bien.
Il y a la même chose pour gtk+ (et pas seulement pour le C++) et je ne vois pas pourquoi ça ne serait pas bien.
C'est tout ce que je dis. Je ne dis pas de faire du C++ avec du C.
Mais la concèption de gtk pour faire des bindings vers d'autre language est un avantage définitif et pas une faiblesse.
Gtk n'a pas essayé de faire du C++ avec C, mais de permettre facilement des binding. Et c'est bien™.
Si Gtk avec un wrapper C++ est une connerie, alors pourquoi personne n'a recodé libxml2 en C++ par exemple ?
Pourquoi il n'y a pas un libX11 en C++ mais seulement des wrappers ? Pourtant c'est tout à fait possible. Pourquoi pas de libX11 en pure python ? C'est aussi tout à fait possible.
Je trouve ça marrant ces critiques des wrappers de gtk+ alors que c'est fait pour plein de librairies.
Rappel : gtk+ n'a pas été faite pour être utilisable uniquement avec C. Les faits montrent que c'est une réussite.-
[^]Re: Performances
Posté par ham () le 25/03/2007 à 18:33. (lien). Évalué à 3.l'envie de nourrir le troll m'est venu,
Faire une lib avec une interface C pour la portabilité c'est bien, vue que n'importe quel langage a une glue pour le C.
Vouloir refaire de l'objet en C pour faire un un truc aussi attractif niveau programation que gtk, c'est une perte de temp
Je pense que vala est la preuve que la maniere dont a été développé GTK a été une erreur technique. Refaire un langage haut niveau qui génére du C GObject aurait du ètre la premiere etape de GTK , pas la derniere.
Quand je vois les possibilité offert au niveau toolkit graphique tel que swing (java), notament gnu classpath, et ce qu'offre GTK, ben je trouve autrement plus efficace de faire et etendre des widget en java qu'en GTK.
le C c'est bien pour faire des truc bas niveau ou trés limité (libX11, libxml2) mais je ne classe pas les interface graphique dans cette catégorie.
Les vrais langage objet sont bien plus facile a utiliser pour faire cela et vouloir programmer un toolkit graphique directement en C est AMHA un mauvois choix technique.
Ensuite si il l'avait fait en java qui sort du C je dirais pas, mais l'efficacité du C est moins bonne, sinon on aurais encore des compilo C++ qui génerais du C , comme au début, mais plus le langage est riche, plus on peut faire d'optimisation au niveau du compilateur et se concentrer sur des truc plus utile comme le framework, les algorithme, la concurence (comme avoir un thread d'affichage, un de collecte d'info de base et un de collecte d'info avancé).-
[^]Re: Performances
Posté par Yusei () le 25/03/2007 à 19:00. (lien). Évalué à 2.je trouve autrement plus efficace de faire et etendre des widget en java qu'en GTK
Je suppose que tu parles de GTK en C, parce qu'étendre un widget GTK en Ruby se fait de la même manière qu'en Java: tu dis de quel widget tu hérites et tu modifies les méthodes qui changent.
Par contre en C c'est pénible, c'est sûr.-
[^]Re: Performances
Posté par ham () le 25/03/2007 à 21:29. (lien). Évalué à 1.Je suis tous a fait d'accord,
Le commentaire pour l'extensions des widgets est surtout orienté extensions dans la lib, i.e plus de feature dans la lib.
Par exemple un menubar++ qui permet de changer l'orientation des menus,
ou autre truc bizzares,
Si c'est vraiment utile c'est mieurx de l'avoir dans la lib que de tout recoder dans chacun des langages cibles,
mais un truc que tu peut faire en 5 min en langage haut niveau, tu risque de mettre 1 semaine a le faire en C, avec plein de bugs.
C'est la ou le choix du C en tant que langage pour faire un toolkit graphique risque de limiter les évolutions des feature du tooklits.
-
-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 19:44. (lien). Évalué à 1.> Je pense que vala est la preuve que la maniere dont a été développé GTK a été une erreur technique. Refaire un langage haut niveau qui génére du C GObject aurait du ètre la premiere etape de GTK , pas la derniere.
Plusieurs années après la sortie de gtk2, c'est facile à dire...
M'enfin tu montres que GObject est une bonne chose.
N'hésites à recoder gtk en vala si ça te chante. Bon courage. N'oublie pas de conserver des performances correctes.
> Quand je vois les possibilité offert au niveau toolkit graphique tel que swing (java), notament gnu classpath, et ce qu'offre GTK, ben je trouve autrement plus efficace de faire et etendre des widget en java qu'en GTK.
Bizarre, eclipse utilise gtk. Dans 7 ou 8 ans je pense que tu vas faire la leçon à eclipse.
> Quand je vois les possibilité offert au niveau toolkit graphique tel que swing (java)
Pour ton info, Java (la version officielle) utilise gtk pour swing :
http://ensode.net/java_swing_mustang_screenshots_gtk.html
M'enfin, c'est encore moi qui trolle, qui suit de mauvaise fois, etc...
> le C c'est bien pour faire des truc bas niveau ou trés limité (libX11, libxml2) mais je ne classe pas les interface graphique dans cette catégorie.
Et gdk ? Et pango ?
Il y a des aspects critiques en performance dans gtk (les grosses listes, le positionnement des widgets, le calcul de la taille sur l'écran d'une chaine, l'affichage en fonction du thème, etc). Regardes java, etc, pour le toolkit il passe par gtk ou équivalent.
Un toolkit écrit uniquement en java ou python serait une catastrophe niveau performance. J'en suis à 100 % convaincu.
Coder l'utilisation d'un toolkit peu raisonnablement se faire avec un language de haut niveau type java/python/etc.
Coder le toolkit, j'y crois pas. Et d'ailleurs ça ne c'est jamais vu. Du moins je ne l'ai jamais vu.
Pour info, swing n'est pas écrit uniquement en java. Il est aussi écrit en C.-
[^]Re: Performances
Posté par ham () le 25/03/2007 à 21:13. (lien). Évalué à 1.Tu peut m'expliquer (ou filer des pointeurs) pourquoi GObject est une bonne chose?
Desc comparaisons de performance sur l'héritage, les possibilité de polymorphisme, la facilité d'écriture en GObject + C ?
Pour ce qui est de dire que GTK c'est bien parceque SWT l'utilise, je voudrais faire remarquer que motif a des tonnes de features super avancé, la preuve eclipse utilise motif, avec eclipse et motif tu peut faire des widget super génials....
Pareil pour swing et GTK, swing (qui utilise AWT si mes souvenirs sont exactes) peut aussi utiliser plusieurs toolkit, dont GTK.
Ton lien est en effet trés intéressant, les gens sont content parceque swing va avoir une apparence comme GTK.
Bref des toolkit multiplateforme peuvent utiliser GTK, cela ne veut pas dire que GTK fournit tout ce que fournit le toolkit qui l'utilise pour le dessins.
Pango c'est pas fait pour dessiner des polices? GDK c'est pas une lib pour dessiner?
Si oui ce sont en effet des éléments d'un toolkit graphique, mais un toolkit graphique c'est plus que ca, c'est plutot des collection d'elements graphique et la maniere de les faire interagir.
mais bon, j'ai assez nourris le troll, le
Coder l'utilisation d'un toolkit peu raisonnablement se faire avec un language de haut niveau type java/python/etc.
Coder le toolkit, j'y crois pas. Et d'ailleurs ça ne c'est jamais vu. Du moins je ne l'ai jamais vu.
me fait douter, j'ai jamais vu des gens coder l'utilisation d'une interface en C.
mes si tu est sur a 100% , que tu y croit, ou pas d'ailleur, comme tu veut mais c'est pas ce que j'appelle un argument technique.
Si coder un toolkit en java c'est du jamais vu, je te conseille awt ou swt.
On peut meme coder des micro-kernel en C++, L4Ka::Hazelnut, voir en java (sur des proc java pourquoi pas).-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 21:49. (lien). Évalué à 1.> Tu peut m'expliquer (ou filer des pointeurs) pourquoi GObject est une bonne chose?
Non, c'est que de la connerie. GObject c'est une daube.
> Desc comparaisons de performance sur l'héritage, les possibilité de polymorphisme, la facilité d'écriture en GObject + C ?
Ça pue GObject. Une perte de temps et en plus ça fait un trou dans la couche d'ozone.
> Pour ce qui est de dire que GTK c'est bien parceque SWT l'utilise
Ouais, mais les connards derrières eclipse, java et swing sont passés à gtk.
Franchement, la planète est peuplée de connards
> je voudrais faire remarquer que motif a des tonnes de features super avancé, la preuve eclipse utilise motif, avec eclipse et motif tu peut faire des widget super génials....
Mais t'as raison, Motif roxor.
M'enfin l'humanité n'est pas encore prête et Motif est abandonné. Faut prévoir son retour au 31ième siècle quand on aura tous un QI de 400. Trop tard pour moi, c'est con.
> la preuve eclipse utilise motif
Malheureusement pas pour longtemps. C'est seulement un option pour ceux qui ont su reconnaitre l'immense supériorité de Motif sur Gtk.
Il faut en profiter un max avant que gtk pourrisse eclipse définitivement.
> Pareil pour swing et GTK, swing (qui utilise AWT si mes souvenirs sont exactes) peut aussi utiliser plusieurs toolkit, dont GTK.
Pire que ça, il va utiliser gtk par défaut. Une horreur. En trois mots : une catastrophe industrielle.
> Bref des toolkit multiplateforme peuvent utiliser GTK, cela ne veut pas dire que GTK fournit tout ce que fournit le toolkit qui l'utilise pour le dessins.
T'as raison, swing qui utilise gtk par défaut c'est un bon de 10 ans en arrière.
> j'ai jamais vu des gens coder l'utilisation d'une interface en C.
Ça doit être une légende alors. Et je ne l'ai jamais fait (pour moi : passer à corriger mon C.V.).
$ repoquery --whatrequires --queryformat="%{NAME}\n" libgtk-x11-2.0.so.0 | sort | uniq | wc -l
578
Merde, il doit y avoir un bug dans repoquery
> Si coder un toolkit en java c'est du jamais vu, je te conseille awt ou swt.
Swt utilise gtk il ne recode pas tout le toolkit. Ou alors c'est une légende ? Pour awt, je n'en sais rien.
> On peut meme coder des micro-kernel en C++, L4Ka::Hazelnut, voir en java (sur des proc java pourquoi pas).
On peut. Quelle dommage que le dictateur Linus Torvalds ait choisi le C.-
[^]Re: Performances
Posté par ham () le 26/03/2007 à 08:22. (lien). Évalué à 1.Donc si swing utilise GTK directement, tous ce qui est disponible dans swing l'est forcement dans GTK non?
Le dialogue d'ouverture de fichier est donc le meme, on peu editer du RTF, parser du HTML avec exactement les mem fonctionalité avec GTK?
Si tu sait coder l'utilisation d'une interface en C ca m'interesse pour mes tests, c'est super pratique pour detecter les bug d'utilisation d'interface.
Ton argument c'est que un ou plusieurs toolkit de haut niveau (SWT;Swing) utlisent GTK, donc GTK c'est bien.
Ma remarque c'est que ces toolkits haut niveau utilisent les fonctions les plus basiques des toolkits systèmes,
les fonctionalité importante du toolkit (widget, architecture et API) sont recodé au dessus et n'ont rien a voir avec le toolkit de base.
Mais bon je te conseille vraiment de corriger to CV,
parceque coder l'utilisation d'une API c'est plutot décrire comment utiliser une API,
ca ressemble a des pre-condition, post-condition, comportement de l'interface, ... etc
De plus les seuls arguments avancé c'est "je peut voir des boutons GTK avec eclipse, GTK c'est bien"
C'est pas trés convainquant pour les capacité de recherche, d'analyse et de synthèse d'un Pb.
Je ne corrige pas de CV, mon orthographe est trop lamentable pour ca.
-
[^]Re: Performances
Posté par golum () le 26/03/2007 à 10:51. (lien). Évalué à 2.
Tu peut m'expliquer (ou filer des pointeurs) pourquoi GObject est une bonne chose?
... Ouais, mais les connards derrières eclipse, java et swing sont passés à gtk.
Franchement, la planète est peuplée de connards
Belle argumentation technique sur les qualités de GObject.
Tu m'impressionnes chaque jour un peu plus
> je voudrais faire remarquer que motif a des tonnes de features super avancé, la preuve eclipse utilise motif, avec eclipse et motif tu peut faire des widget super génials....
Mais t'as raison, Motif roxor.
M'enfin l'humanité n'est pas encore prête et Motif est abandonné. Faut prévoir son retour au 31ième siècle quand on aura tous un QI de 400. Trop tard pour moi, c'est con
Sauf que le mr te repondais sur le fait que ce n'est pas parce que Eclipse utilise Gtk que c'est un gage de qualité. Motif aussi donc selon tes arguments Motif dechire forcément. Merci de demonter ton raisonnement par la dérision à sa place
Bref des toolkit multiplateforme peuvent utiliser GTK, cela ne veut pas dire que GTK fournit tout ce que fournit le toolkit qui l'utilise pour le dessins.
T'as raison, swing qui utilise gtk par défaut c'est un bon de 10 ans en arrière.
Tu relis ce à quoi tu réponds des fois. que gtk ou n'import quel lib soit utilisée importe peu puisque c'est les primitives bas niveau qu sont utilisées. Les Widgets et autres layout qui dechirent sont tous réimplémentés dans SWT/JFace.
> Si coder un toolkit en java c'est du jamais vu, je te conseille awt ou swt.
Swt utilise gtk il ne recode pas tout le toolkit. Ou alors c'est une légende ? Pour awt, je n'en sais rien.
Non mais que ce soit AWT ou SWT la réutilisation est mince. Même si AWT utilise encore moins les services du tk hôte que SWT.
http://www.jguru.com/faq/view.jsp?EID=507891
Ceci aurait tendance à me conforter dans l'idée que GTK n'est pas un foudre de guerre quand on compare les perfs d'eclipse sous Win32 ett Gtk. L'appoche AWT est encore pire mais ca ne dédouane pas Gtk pour autant. On sait pourquoi ca rame alors qu'avec SWT/gtk il y a de quoi se poser la question.
-
-
-
[^]Re: Performances
Posté par golum () le 26/03/2007 à 09:25. (lien). Évalué à 3.
Bizarre, eclipse utilise gtk. Dans 7 ou 8 ans je pense que tu vas faire la leçon à eclipse.
Eclipse utilise SWT qui n'utilise que quelques primitives graphiques d GTK.
Il y a eu un port de SWT vers Qt mais ce qui posait pb etait la license à l'époque.
D'ailleurs, en comparant les perf d'eclipse sous windows et sous Linux on se dit que GTK n'a pas de quoi pavoiser.-
[^]Re: Performances
Posté par golum () le 26/03/2007 à 09:42. (lien). Évalué à 2.Bon concernant les perfs je retire ce que j'ai dit parce qu'il n'y a pas que la lib qui intervient. L'implementation de la JVM doit y être pour beaucoup. Faudrait tester en compilé pour mieux se rendre compte.
-
[+] [^]Re: Performances
Posté par ola () le 26/03/2007 à 14:56. (lien). Évalué à -2.Je valide, pour avoir benche differentes jvm (sun/ibm sous windows/linux), la jvm sun pour linux est une daube sans nom.
Et je valide aussi qu'eclipse linux est d'une lenteur sans non sur ma babasse perso (athlon 1600+XP/768Mo ram) alors qu'il tourne plus que decemment sur un windows sur la meme machine.
-
-
[^]Re: Performances
Posté par ola () le 26/03/2007 à 14:54. (lien). Évalué à 0.pour etre tout a fait exhaustif : SWT est porte pour GTK et Motif.
Et aussi pour win32 (trou de memoire pour le nom de l'api) et aqua ('fin le machin de chez appeule)
Et il ne s'en sert effectivement que pour les primitives graphiques, toute l'ihm derriere et faite en java.
-
-
-
[^]Re: Performances
Posté par IsNotGood () le 25/03/2007 à 19:51. (lien). Évalué à 3.De façon général, ça fait depuis des années que ça trolle sur gtk, que c'est pourri, que GObject c'est de la connerie, que l'utilisation du C est une aberration, etc...
Ben gtk est le toolkit de référence sous Unix. Utilisé par Java, Gnome, eclipse, XFCE, OOo, Mozilla (firefox etc), gimp, Inkscape, etc...
Vient après Qt en popularité. Je ne dit pas que Qt est moins bien, mais le gros atout de gtk par rapport à Qt c'est ses bindings.
Dans 10 ans ça continura de troller.-
[^]Re: Performances
Posté par lezardbreton (Jabber id, page perso, ) le 26/03/2007 à 08:24. (lien). Évalué à 3.Regarde plus du côté de la licence que du côté des qualités techniques pour expliquer sa popularité. Personnellement, sur mes ordinateurs, c'est bien sûr QT qui est le plus populaire, et de très loin.
-
[^]Re: Performances
Posté par alice_liddell () le 26/03/2007 à 08:25. (lien). Évalué à 3.Ben gtk est le toolkit de référence sous Unix. Utilisé par Java, Gnome, eclipse, XFCE, OOo, Mozilla (firefox etc), gimp, Inkscape, etc...
Swing (java) et VCL (OpenOffice) utilise GTK?-
[^]Re: Performances
Posté par Étienne Bersac (Jabber id, page perso, ) le 26/03/2007 à 15:31. (lien). Évalué à 3.aah c'est VCL le toolkit d'OpenOffice … quelle peste !
--
E Ultreïa !
-
-
[^]Re: Performances
Posté par Benoît Guédas (Jabber id, ) le 26/03/2007 à 09:17. (lien). Évalué à 4.Ouais, et windows est largement plus utilisé que linux, preuve de sa grande supériorité technique...
-
-
[^]Re: Performances
Posté par Étienne Bersac (Jabber id, page perso, ) le 26/03/2007 à 15:23. (lien). Évalué à 4.Les interfaces en Java, c'est une vrai plaie ! Rien que ces listeners c'est pourri comparé aux signaux de Gtk+ et aux slots de Qt.
T'es pas obligé d'étendre ton Widget en C, tu peux le faire dans n'importe quel langage ayant une passerelle vers C/GObject. Évidemment, ce sera plus dur d'exposer ton super nouveau Widget vers d'autre langage une fois que t'aura choisie python ou ruby.
C'est d'ailleur pour ça que j'utilise C/GObject directement pour gnome-scan, je veux un bindings python, C++, perl, ruby, … et un vapidef :)
Étienne--
E Ultreïa !
-
-
[^]Re: Performances
Posté par golum () le 26/03/2007 à 09:10. (lien). Évalué à 3.Arrrêtes ta mauvaise foi.
On ne critique pas le C.
Ce qu'on t'explique c'est que coder un tk graphique qui sous-tend des concepts résolument objets avec un langage qui ne l'est pas est une mauvaise stratégie.
T'as beau invoquer Linus, libx11 et toutes les libs de bas niveau C de Linux/X11.
Leur conception n'est pas objet donc il n'y a pas de raison d'utiliser le C++.
Peu importe qu'il y ait des bindings. Personne ne le conteste mais
le langage d'implementation par défaut conditionne le reste.
On va pas se taper toutes les libs et tous les interpréteurs de la création pour implementer la lib GTK (sinon bonjour les dépendances). On utilise UN langage et on permet aux applis clientes d'utiliser leur propres langages pour communiquer. C'est le minimum attendu et je vois pas en quoi Gtk serait plus une réussite à ce niveau que Qt ou les ports pour Gnustep.
Ce qu'on t'explique c'est qu'il faut utiliser le bon outil pour la bonne tâche. Si t'en es là pourquoi ne pas recoder le kernel entièrement en assembleur plutôt que certaines parties incoutournables. Aucun doute c'est un vrai langage qui roxor sa mère.
Et c'est pareil pour les exemples avec Swt / Swing et wxWidgets
Ces libs sont bien obligées de s'appuyer sur les primitives graphiques de l'OS (GDI pur Windows et gtk pour linux) . C'est le minimum. Mais pour le reste c'est à dire l'essentiel c'est implenté complétement avec un langage ... objet. Pareil pour wxWidget, Fox, XPToolkit, Gnustep, ... Quasiment tous les tk modernes utillisent un langage objet. Seul les viellissants Motif, GDI et OS/2 PM avaient fait ce choix maias pour combien de temps. OS/2 est mort, Motif agonisant et MS tente le virage C# mais recule devant l'ampleur des dégats.
http://www.free-soft.org/guitool/
Je vais arrêter là car tu vas encore nous ressortir les mêmes pseudo contre exemples et on va tourner en rond.-
[^]Re: Performances
Posté par IsNotGood () le 26/03/2007 à 10:35. (lien). Évalué à 3.> Ce qu'on t'explique c'est que coder un tk graphique qui sous-tend des concepts résolument objets avec un langage qui ne l'est pas est une mauvaise stratégie.
Très bien, mais j'ai dit plus 400 000 fois que la force de gtk est ses bindings.
Si pas de binding, le C++ c'est mieux.
En passant, je développe aussi en C++ et je préfère le C++ au C.
Mais le fait que je préfère le C++, que le C++ soit supérieur au C, n'est pas un raison que gtk a eu tord d'être écrit en C. Gtk n'a pas été écrit en C pour l'amour du C mais pour avoir les binding.
Alors vous pouvez continuer à dire que gtk en C c'est une connerie, mais les faits sont là : gtk a des binding, beaucoup, et ils marchent bien.
Qt a quelques bindings avec un ou deux qui marchent bien.
Si un des principaux objectifs est d'avoir des bindings, gtk a eu raison d'être écrit en C, de faire GObject, etc... Les faits le démontre.
> Leur conception n'est pas objet donc il n'y a pas de raison d'utiliser le C++.
Tu t'emballes un peu. Certe libX11 n'est pas libXt, mais l'idée est là.
C'est Kernighan qui disait que tout bon programme C est orienté object. Du montant que tu as des structures et que tu y associés des fonctions (de façon directe ou non avec les pointeurs de fonction, en utilisant des types, etc) c'est de la programmation object. Ou dit que c'est de l'encapsulation de données si ça vexe ta haute idée de la POO.
En passant, la POO n'est pas réservée à aux languages dédiés POO. Linux est un assez bon exemple de POO. Lis les sources pour t'en convaincre.
Il y a des concepts qui s'exprime naturellement en objet et aussi en C. Le "FILE *" de la libc, c'est définitivement un object. Trouve ça horrible si tu veux (je trouve ça moche aussi à côté des facilités C++), mais c'est un object.
> Peu importe qu'il y ait des bindings.
Non. Et je ne comprend pas ce type argument qui flirt avec le ridicule. Le choix du C pour gtk c'est les bindings. Donc ne critiquez pas ce choix sans considérer les bindings, sans considéré les objectifs de gtk.
Si tu définis les objectifs de gtk alors oui gtk aurait dû peut-être être fait dans un autre language. Mais pourquoi on choisi un language ? Car on a des objectifs.
Il faut faire une interface pour une base de donnée, VB est un bon choix. Il faut faire une interface pour un automate avec des contraites temps réel, une interface très riches qui remonte beaucoup d'info, alors VB est un mauvais choix.
Ignorer les objectifs dans le choix d'un language est une aberration.
> le langage d'implementation par défaut conditionne le reste.
Tu l'as dit.
> On utilise UN langage et on permet aux applis clientes d'utiliser leur propres langages pour communiquer. C'est le minimum attendu et je vois pas en quoi Gtk serait plus une réussite à ce niveau que Qt ou les ports pour Gnustep.
Rires. Si C++ roxe des ours dans tous les domaines et même pour faire des bindings, pourquoi Qt en chie pour avoir des bindings ?
Tu m'expliques ça ?
Manque de popularité ?
Ça m'étonnerais, vois comme je me fais moinser pour "défendre" gtk.
KDE utilise plein de lib en C. KDE peut piocher dans les librairies C et si besoin faire un wrapper C++. KDE mais aussi python, perl, java, C#, ada, php, etc... L'inverse est rare. Tu m'expliques ça ?
Et ce n'est pas de la mauvaise fois de ma part ou du troll ou autres conneries dans ce goût dont on m'accuse, c'est un FAIT.
> Ce qu'on t'explique c'est qu'il faut utiliser le bon outil pour la bonne tâche.
Les faits montrent que gtk a utilisé le bon outil pour la tâche d'avoir des bindings.
> Si t'en es là pourquoi ne pas recoder le kernel entièrement en assembleur plutôt que certaines parties incoutournables.
???
Il y a des objectifs, parfois le C est adapté, parfois le C++, parfois VB, parfois l'assembleur.
Mais pour les objectifs de gtk, le C++ n'est pas adapté.
> Mais pour le reste c'est à dire l'essentiel c'est implenté complétement avec un langage ... objet.
Pourquoi pas. Et gtk le permet.-
[^]Re: Performances
Posté par golum () le 26/03/2007 à 11:22. (lien). Évalué à 2.Tu deviens un peu plus interessant quand tu arrêtes de troller.
Fort bien l'un des objectifs de Gtk est de fournir des bindings pour tous les langages de la création.
Seulement sa conception est basée sur l'objet.
Dès que tu l'utilises avec un langage qui se réfère à un autre paradigme tu es forcé de simuler celui de l'objet. Faire du fortran objet , quel intêret ?
Qt s'est fixé pour objectif de faire une lib bien conçue et ce qui permet d'entreprendre des changements de conception plus simplement. Les bindings vers les pricipaux langages existent aussi. Donc l'objectif est rempli également. Je ne vois pas en quoi Qt en chie comme tu dis .A la limite c'est sûr que pour des langages procéduraux la tâche est plus ardue. Rendre un hériatage multiple avec du C ne doit pas être évident par exemple.
Les bindings comme PyQt se focalisent sur le fait d'apporter des fonctionnalités supplémentaires propres au lanage hôte (comme par exemple etendre les signaux/slot en dynamique).
En passant, la POO n'est pas réservée à aux languages dédiés POO. Linux est un assez bon exemple de POO. Lis les sources pour t'en convaincre.
Il y a des concepts qui s'exprime naturellement en objet et aussi en C. Le "FILE *" de la libc, c'est définitivement un object. Trouve ça horrible si tu veux (je trouve ça moche aussi à côté des facilités C++), mais c'est un object.
sauf que le seul mécanisme que tu cites est l'encapsulation et encore de façon imparfaite. Ce n'est qu'un des concepts de la POO. dès que tu la fait intervenir avec l'héritage, le C montre ces limites. Les cast de structures ne résolvent pas tous les problèmes. Lorsqu'il s'agit d'encpasuler les opérations et d'hériter des comportements on se retrouve vite avec des pbs set on doit alors rajouter moulinettes dans tous les sens ou faire preuve de riguer au lieu de se reposer sur lel angage.
Ne parlons pas du polymorphisme. Avec du C et l'utilsation intensive du void* tu peux te retrouver assez facilement avec des core dumps. Chose qu'un langage objet est capable de gérer. (Compilation impossible avec un langage statique, Exception avec
Ne parlons pas du multi-héritage, de la façon de gérer les exceptions , ... )
Sinon si tu veux parler de KDE, compare le avec Gnome et son Mono/C# pas avec Gtk.-
[^]Re: Performances
Posté par yoplait () le 26/03/2007 à 11:47. (lien). Évalué à 3.Vous êtes si bien partis que je suppose que ce ne sera pas le mot de la fin, mais je ne peux pas m'empêcher de citer Havoc :
Why does Gnome use C for object-oriented programming?
HavocPennington: It's just history. There isn't any big reason.
Les bindings, les performances, c'étaient peut-être de bonnes raisons il y a 10 ans, mais plus vraiment maintenant. Je crois qu'il y a consensus sur ce sujet.
-
[^]Re: Performances
Posté par IsNotGood () le 26/03/2007 à 14:54. (lien). Évalué à 2.> Fort bien l'un des objectifs de Gtk est de fournir des bindings pour tous les langages de la création.
> Seulement sa conception est basée sur l'objet.
Et ?
Je ne vois pas le problème. Dans Linux il y a plein d'objets aussi. En quoi passer à C++ rendrait Linux meilleur ?
Pourtant Linus a voulu un certain temps passer à C++. Mais il a trouvé qu'il y avait des problèmes et a abandonné l'idée. Désolé, je ne connais pas les détails de l'affaire. Je les connais dans les grandes lignes mais l'expliquer ici serait long et hazardeux. Principalement des problèmes d'optimisation.
Même si un langage n'est pas adapté à la POO, pourquoi s'interdir de faire de la POO ?
Il y a ici quelque chose qui m'échate.
Comme tu veux implémenter par exemple des menus sans faire de programmation object ou seulement en utilisant un paradigme procédural ?
Voilà un menu :
struct menu {
bool sub_menu ;
void* action_or_menu ;
...
} ;
struct menu main_menu[] = { true, menu_fichier}, {false, display_about}} ;
Ok, c'est immonde, mais c'est d'idée qu'il faut suivre.
C'est de la programmation objet et c'est très courant en C.
> Dès que tu l'utilises avec un langage qui se réfère à un autre paradigme tu es forcé de simuler celui de l'objet.
Ça dépend comment tu penses. L'exemple précédent ne simule pas de l'objet. C'est de l'objet. Si tu penses structures de données, pointeurs de fonction, il se peut que tu ne te rendes pas compte que c'est de l'objet.
Si l'objet pour toi demande systématiquement de l'édition de lien dynamique, des type utilisateur, etc... alors pour faire de l'objet en C il faut le "simuler" et rentrer dans des techniques pas évidentes à mettre en oeuvre. Mais c'est ta conception de la POO, c'est ta façon d'aborder la programmation qui te fait penser que le C ne doit pas être utiliser pour faire de la POO.
Je peux t'assurer qu'on peut être redoutablement efficace en C même en faisant de la POO. Par contre si tu veux tout le luxe de la POO en C, c'est beaucoup plus lourdingue de le faire. Notes que faire une librairie C++ avec tout le luxe de la POO, c'est aussi beaucoup de boulot (et même beaucoup plus qu'on ne le croit en général).
Un autre exemple de programmation object très courrant, c'est tout ce qui est lié aux bases de données. Chaque enregistrement est une instance d'un object, ils ont des propriétés, par contre les méthode ne sont pas dans la base de donnée (ou rarement). Mais il y a souvent ici le paradigme POO d'appliqué.
Dès que tu fais un système de plugins, tu fais de la programmation objet. Et si c'est en C, ce n'est pas un cauchemard à réaliser.
> Qt s'est fixé pour objectif de faire une lib bien conçue
Qt est une superbe librairie.
> Les bindings vers les pricipaux langages existent aussi.
Certe.
> Je ne vois pas en quoi Qt en chie comme tu dis .
Un exemple :
http://developer.kde.org/language-bindings/java/ Pas vraiment complet. Et pourtant Java est object "comme" Qt.
Java pour gtk (mais aussi gconf, gnome, gstreamer, etc) existe depuis un bon moment.
> Donc l'objectif est rempli également.
Tout est possible. Théoriquement je ne vois pas pourquoi il n'y aurait pas de binding pour Qt. Mais c'est lourd à mettre en oeuvre. D'autant plus si Qt veut utiliser toutes les fonctionnalités du C++.
> Les cast de structures ne résolvent pas tous les problèmes. Lorsqu'il s'agit d'encpasuler les opérations et d'hériter des comportements on se retrouve vite avec des pbs set on doit alors rajouter moulinettes dans tous les sens ou faire preuve de riguer au lieu de se reposer sur lel angage.
Ben oui. Et plus tu montes la barre haut en exigence de fonctionnalités, plus tu as des difficultés pour faire des bindings, plus tu es exigent envers le language à "binder", moins tu es ne
-
-
-
-
-
-
-
-
-
-
-
-
-
-
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.