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

[ Répondre ]

Salut,

À mon avis, ça doit se debogué comme du pygtk. Sauf si on tombe sur une bogue de vala. C'est clair cependant, que savoir ce qui se passe sous le capot n'est pas inutils, comme partout … Faudrait voir ça en détail avec les dévs de Vala.

Étienne.

[ Répondre ]

L'avantage de Vala, c'est qu'il est conçu pour GObject, contrairement à python et C# pour reprendre tes citations.

> pour moi vala ça ressemble à une défaite des principes qui sous-entendent l'utilisation du C par gnome

Vala est loin d'être le futur langage de Gnome. Ça fait belle lurette que Gnome n'est pas écrit totalement en C/GObject. C++, Java, C#, perl et Python ont leur passerelles dans Gnome ( http://live.gnome.org/TwoPointNineteen/Bindings ). Le GObject a été conçu avec deux objectifs :

* avoir une API object en C
* passerelle automatique et transparente pour d'autre langages compilés où interprêté.

( cf. http://developer.gnome.org/doc/API/2.0/gobject/chapter-intro(...) ).

Dans le concept même de GObject, il n'y a pas l'exclusivité du C/GObject. Gnome se veut agréable pour l'utilisateur mais aussi le développeur en lui laissant le choix du langage (autant que possible). Vala n'est et ne sera qu'un choix de plus dans la liste !

Étienne.

[ Répondre ]

gnome-vfs est pas franchement une techno apprécié de gnome. Cf. vio sur freedesktop. http://lists.freedesktop.org/archives/xdg/2007-January/00914(...)

[ Répondre ]

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

[ Répondre ]

> 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.

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

Salut,

J'aurai utilisé plutôt "juste-à-temps" plutôt que "juste au bon moment".

Mes 2 sous.

Étienne.

[ Répondre ]

Le truc c'est que ces améliorations ne sont pas dans Xorg. Bizarre pour r200, j'ai notamment une 9250 qui fonctionne du tonnerre.

[ Répondre ]

Je ne sais pas. r200 est plutôt réputé comme pilote (plus performant que celui d'ATI).

Étienne.

[ Répondre ]

> l'élimination de certaines vieilleries telles que xmms (non sans saluer et remercier les développeur de ce projet au passage) et gdk-pixbuf

J'ai du mal à croire que GdkPixbuf soit une vieillerie. Ça mérite éclaircissement !

Étienne.

[ Répondre ]

T'inquiète, ici sur MacBook, Apple Remote et clavier fonctionne impeccable avec feisty !

[ Répondre ]

Salut,

J'écrit ce message depuis Ubuntu Feisty Fawn sur un MacBook acheté en octobre en wifi WEP.

Ce qui fonctionne :
- le son
- les touches multimédia
- le bluetooth (Mighty Mouse bluetooth)
- la batterie (jauge, évènements, etc.)
- l'accélération graphique (OpenArena roxor)
- clavier FR impeccable (notamment avec ma carte clavier + le dernier xkeyboard-config de debian-powerpc dispo dans feisty).
- Apple Remote ( rhythmbox et totem réagissent aux touches multimédia)
- l'écran avec 915resolution
- gravure (cd, dvd, etc.)
- wifi (avec mad wifi : non-libre)
- régler la lumosité
- usb, firewire, jack
- sortie mini-DVI externe en mode copie.
- le bi-c½ur est reconnus
- carte ethernet


Ce qui ne fonctionne pas :
- suspension (hibernation fonctionne)
- le micro (ça dépend de l'iSight je pense).
- la molette de la souris foire en bluetooth (pas en USB)

Ce qui fonctionne avec bidouille :
- iSight (faut charger manuellement le firmware).

Pas testé :
- supension (faut désactiver l'IDE à ce qu'il paraît, en gros, pas de CD :| ).
- WPA
- table de partition GPT (faut grub2).
- bureau étendu avec écran externe

Ubuntu edgy marchait tellement bien que j'ai viré OS X, contrairement à l'iMac G5 rev C sur lequel j'ai toujours le dual boot (mais ça vient : http://linuxfr.org/~bersace/24004.html )
Tout ça sans bidouille, sans Mac OS X, sans BootCamp, uniquement le CD d'edgy inséré. Bravo GNU/Linux !

Étienne.

[ Répondre ]

Salut,

Peut-être. Il faudrait le modèle de la carte pour être sûr. Après de radeon 9250, c'est r300.

Étienne.

[ Répondre ]

Bonjour,

Après discussion avec BenH, le problème de performance est dû au gestionnaire de mémoire de r300 qui est pourrie en attendant que celui de tungsten gfx (utilisé par i810) soit fini et utilisé par r300 (et les autres).

Il n'accélère pas les copie 2D en envirronement 3D, ce qui fait foirer le défilement.

Mes 2 sous.

Étienne.

[ Répondre ]

ATI Radeon X600 XT Pro !!!!
Chipset R380

Cependant, le CPU travaille encore pas mal.

[ Répondre ]

Merci aux admin d'avoir au moins ajouté la traduction. La version anglaise est toujours inutile …

Étienne.

[ Répondre ]

> Cette volonté d'intégration me fait peur et va a l'encontre de la philosophie unix (mais elle est en plaine accord avec celle de Windows).

J'aurai dit tout le contraire. Sous Windows®, les interfaces graphiques sont très hétérogène, même parmis les interfaces de Microsoft® même. Alors que dans le libre, que ce soit Gnome, GNUStep ou KDE, les applis sont beaucoup plus homogène.

Ensuite, quand on voit les standards des lignes de commande GNU. Ex: les options avec les variantes courtes et longues, etc. GNU tend à homogénéiser les interface de commande.

Enfin, alors que sous Windows®, chaque logiciel a son dossier dans Program Files et se démerde avec ses DLL et ses données, les logiciel UNIX ont leur dossier où s'installer, sinon c'est la merde (LD_LIBRARY_PATH à modifier, etc.). Au final, on impose /usr/bin, /usr/lib, /usr/include, /usr/share/, etc.

> Et voila: cela marche mais juste si tu utilise les applications GNOME pour le reste du systéme il peut aller se faire cuir un oeuf. Voila où mène l'intégration !

Tout à fait d'accord. Peut-être que FUSE va aider à résoudre ça. Il y a des discussion sur gnome-vfs actuellement. Bref, c'est un vrai problème.

/me rêve de Gnome tirant partie des fonctionnalités de Hurd.

Étienne.

[ Répondre ]