Développeur : Rendre GNOME rapide
Posté par ccomb (Jabber id, page perso, ). Modéré le 14 octobre 2005.
Au menu, des explications sur les raisons de certaines lenteurs de Gtk, et sur les multiples façons d'améliorer le tout.
En seulement deux jours de travail, l'auteur (aidé par Billy Biggs, Owen Taylor, Carl Worth et Keith Packard) a déjà réussi à gagner 24% de vitesse sur Pango.
Je vous laisse lire le reste et si certains d'entre vous sont des programmeurs/étudiants/professionnels/passionnés chevronnés disposant d'un peu de temps, n'hésitez pas à participer à cet effort d'optimisation et de profiling, car tout le bureau Gnome et toutes les applications GTK vont en bénéficier d'un coup !
![[en]](../images/en.png)
Le diaporama (2255 hits)-
Les travaux de Federico (1028 hits)
-
Gnome Summit 2005 (339 hits)
-
Le profiler utilisé (749 hits)
> Lire la dépêche (116 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #636969.
Run by 
Cette page a été générée par Templeet en 0.079s (dont 0.0082 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
[+] bla bla bla bla bla bla bla bla bla bla
Il n'y a franchement rien dans cette news.
Où sont le infos utilisateurs pour améliorer les perfs ?
Ce donner des buts c'est bien, les réaliser c'est mieux. On sait tous que le nautilus devrais se lancer le plus rapidement possible; si à chaque idée, amélioration ou correction de bugs ; on "s'amuse" à faire une présentation préliminaire (nulle de plus), on n'est pas sortie.
[^]Re: bla bla bla bla bla bla bla bla bla bla
Il n'y a franchement rien dans ton commentaire: à tu pris le temps de lire les liens donnés?
La présentation ne donne pas seulement les objectifs, mais explique aussi comment ils ont réussi à optimiser pango et le sélecteur de fichier jusqu'à présent. Les articles sur le blog de Federico sont d'ailleurs très instructif à ce sujet.
[^]Re: bla bla bla bla bla bla bla bla bla bla
On sait tous que le nautilus devrais se lancer le plus rapidement possible
Ça me rappelle une question qui me vient souvent au sujet de la lenteur de Nautilus.
Bien qu'il ai moins de fonctionalités (p. ex. il n'utilise pas gnome-vfs), le navigateur de fichier (en gtk) rox-filer ( http://rox.sourceforge.net ) est incroyablement rapide, fulgurant, même sur des machines modestes. Une meilleur intégration dans gnome rendrai gnome utilisable sur les petites configs.
Pourtant rox-filer est snobbé par les distros (aucune ne le propose en alternative à Nautilus lors de l'install de gnome, il n'est pas dans les packages de Debian etc.) et bien sur par le projet gnome lui-même (on peut facilement choisir un mua alternatif à evolution, mais c'est plus difficile pour le gestionnaire de fichiers). Pourquoi ce logiciel, si performant, est ignoré de la sorte ?
[^]Re: bla bla bla bla bla bla bla bla bla bla
Rox-filler n'est jamais proposé en alternative à nautilus, peut être parce que ce n'est pas un programme gnome, c'est le navigateur de fichier du bureau ROX ( bureau à part entière)
[^]Re: bla bla bla bla bla bla bla bla bla bla
Oui oui, bien sûr, ROX n'est pas un programme gnome. Ce que je voulais dire, c'est que dans gnome, il est possible de remplacer (efficacement, simplement, globalement) evolution par sylpheed, epiphany par firefox, abiword par oofice, etc. bref, les applis natives par des applis tierces (eg. venant de KDE).
Gnome permet de configurer de façon globale le mua, le tableur, le traitement de texte, l'éditeur, le navigateur, le lecteur audio/vidéo ... par défault, et c'est intégré dans les principales distros. Mais ce n'est pas le cas pour l'explorateur de fichiers.
rox-filer peut être installé et utilisé totalement indépendament du bureau rox. (et surtout, on peut le compiler à la main, quoiqu'en dise la doc, et eviter leur monstrueux système d'installation par default ;).
rox ne place pas la compatibilité avec freedesktop.org au centre de leurs priorités, ça ne facilte surement pas les choses.
[^]Re: bla bla bla bla bla bla bla bla bla bla
au niveau de la compatibilité avec freedesktop le projet ROX est plutot avancé a certain niveau, les themes d'icones par exemple utilisent les convention de nomage de freedesktop depuis longtemps (et gnome toujours pas) et c'est en general une de leurs préocupations (je suis abonné à la ML). A quoi tu pensais en particulier ?
Sinon je ne peux que le conseiller ROX-Filer, je m'en sert depuis longtemps, je fais chier mon entourage avec ça tout le temps. La rapidité est vraiment une de ses qualité, et l'ergonomie aussi, bref, j'arrete je suis reparti a faire du prosélitisme roxien.
[^]Re: bla bla bla bla bla bla bla bla bla bla
Je l'ai choisi aussi pour ça (rapidité-légèreté) et aussi parce q'il y a eu des histoires pas très sympas dans le développement de nautilus.
Par contre, je prends toujours cher quand je lance
rox /usr/share
(ou /usr/share/bin, /usr/lib, /usr/share/doc, etc)
[^]Re: bla bla bla bla bla bla bla bla bla bla
Par contre, je prends toujours cher quand je lance
rox /usr/share
Je ne vois pas ce qu'il y a d'illogique.
[^]Re: bla bla bla bla bla bla bla bla bla bla
Sort de là Jean Roucas, on t'a reconnu !
[^]probleme nautilus ?
> et aussi parce q'il y a eu des histoires pas très sympas dans le développement de nautilus.
Comme quoi ?
[^]Re: bla bla bla bla bla bla bla bla bla bla
« il n'est pas dans les packages de Debian »
Si si, il s'appelle rox-filer:
http://packages.debian.org/stable/x11/rox-filer
« Bien qu'il ai moins de fonctionalités (p. ex. il n'utilise pas gnome-vfs) »
Apparement c'est possible, mais ça s'active à la compilation:
$ rox --version
ROX-Filer 2.2.0
Copyright (C) 2005 Thomas Leonard.
[...]
Compilé avec GTK version 2.6.8
Tournant avec GTK version 2.6.10
-- fonctionnalités fixées à la compilation --
Support des fichiers longs... Oui
Bibliothèque GNOME-VFS... Non (nécessite au moins 2.8.0)
Support dnotify... Oui
Compatibilité binaire... Non (apsymbols.h non trouvé)
[^]Re: bla bla bla bla bla bla bla bla bla bla
A une époque rox n'était pas dispo sous Debian, ça avait fait pas mal de trolls, je ne me rappelle plus pour quelles raisons ils n'en voulaient pas.
[^]Re: bla bla bla bla bla bla bla bla bla bla
À cause de la façon de disposer ses fichiers. Une des rares choses que je reproche à Debian est de vouloir suivre la LSB
[^]Re: bla bla bla bla bla bla bla bla bla bla
Quel mal y a-t-il à vouloir suivre la LSB, de manière générale ?
[^]Re: bla bla bla bla bla bla bla bla bla bla
Ça interdit à certains programme de disposer leurs fichiers suivant leur manière "naturelle" : Rox, Gnustep, peut être d'autres.
(note, ils sont bien dans debian, mais rox est très modifié, et gnustep a vu le couperet passer pas loin il n'y a pas si longtemps).
Quand des gens proposent des améliorations pratiques, il arrivequ'on leur réponde : "Non, c'est pas compatible avec la LSB". Conclusion? la LSB n'a pas l'air compatible avec les améliorations.
Il y a sûrement des bons pricipes dans la LSB, mais il n'y a pas besoin de tout suivre aveuglément.
[^]Re: bla bla bla bla bla bla bla bla bla bla
Par contre, les devs ne peuvent pas rendre leur programme compatible avec la LSB ? Puisque c'est censé être standard, c'est peut-être un bon calcul pour le long terme de s'y conformer.
L'incompatibilité Standard/innovation est courrante. Par définition, un standard est un consensus. Le temps que l'innovation arrive à pointer son nez, elle n'est généralement plus innovante, mais 'best practice'.
Au pire, il reste /opt.
Adrien
[^]Re: bla bla bla bla bla bla bla bla bla bla
ROX et GNUstep utilisent un système similaire de "bunde".
C'est en gros un super répertoire avec le(s) binaire(s) et toutes les ressources nécéssaires au programme. Ca évite aux fichiers d'un logiciel d'être éparpillés partout dans le système de fichier et simplifie l'installation/déinstallation/déplacement des applications : un simple drag&drop suffit !
Le problème c'est que ce n'est pas du tout une façon de faire conforme à la LSB (ce dont à priori se foutent les gens de GNUstep qui vise à faire un Next-like et pas juste un système GNU).