tgl a écrit 1743 commentaires

T'as regardé si il n'y avais pas des packages du module FUSE de dispo pour le kernel Ubuntu ? Ou sinon, si t'as les headers de ton noyau, tu peux toujours te le compiler à la mimine. Enfin bref, tout ça pour dire que y'a pas besoin d'un 2.6.14 pour jouer avec FUSE. Perso, ça fait bien plus d'un an que je l'utilise comme ça, compilé à côté.

SDL ferait probablement ce que tu cherches. Certes, elle en fait aussi beaucoup plus (3D, audio, tout ça), mais bon, c'est pas si grave. Elle a quand même plein d'avantages :
- multi-plateforme (au moins Linux / Windows / OsX)
- pas mal de bindings (perl, python, etc.) si tu fais pas du C
- la plus utilisée pour les jeux, donc déjà installées chez la plupart des gens (et dispo de toute façon dans toutes les distros courantes)
- bien documentée, y'a des tutoriaux un peu partout sur le web
- très stable (autant au sens "pas planter" que au sens "pas bousiller l'API à chaque nouvelle version")
- existence de pas mal de bibliothèques complémentaires pour pas réinventer la roue dans les autres tâches courantes de la programmation de jeux (genre SDL-gui pour les menus, SDL-net pour le réseau, etc.)

Bref : http://www.libsdl.org

Après, l'install sous Mandrake, j'en sais trop rien, mais a priori ça doit pas être compliqué... Sûrement un truc du genre "urpmi libSDL libSDL-devel" (le machin-devel étant le paquet des headers).

> ben pas trop en fait, >& permet de diriger stdout et stderr sur le mm fichier (/dev/null),
>
> T'es sur que ca marche en sh ce truc, et que c'est pas du specific bash?

Il pense en fait à "&>" je pense. "cmd &>/dev/null", c'est un raccourcis pour "cmd >/dev/null 2>&1", enfin bref "&>" est une redirection des deux sorties à la fois.

Ça existe au moins en Bash, mais je ne sais pas si c'est du pur Bourne shell ou pas.

> Brulons les modérateurs alors :-)

Bon, je note le smiley, mais quand même, juste au cas où l'idée aurait traversé certains avec moins d'humour : entre hier soir et ce matin, 3 modérateurs/relecteurs sont passés sur la dépêche, pour effectuer 7 passes de correction. Et il en a fallu 6 pour atteindre le quota de votes. Ça n'est certes pas du pur stakanovisme non plus, mais c'est finalement pas si mal pour des gens qui dans le même laps de temps ont probablement aussi dormi, réchauffées leurs pizza, pris le metro, et autres conneries dispendieuses en temps dit libre.
En fait, idéalement, et même si je conçois parfaitement que ça n'est pas toujours possible pour Albert & co, si ces niouzes pouvaient arriver plutôt le mercredi matin, ça serait idéal ; en journée, boulot oblige, les modéros sont souvent plus disponibles, moins mobilisés par les contingences de la vie réelle, et l'annonce serait ~assurée d'être publiée dès le mercredi aprèm', soit plus de 24 heures avant l'emission.
Sur ce, je vous laisse mettre des smiley où bon vous semble... enfin sauf celui là :)

> En revanche je n'arrive à y accéder que de cette façon :
> ${PIPESTATUS[0]}

Oops, oui bien sûr, typo...

Je ne sais pas si c'est du Bourne shell de base ou pas, mais en Bash au moins il existe une variable $PIPESTATUS qui est un tableau des différents codes de retour de la dernière série de commandes exécutées.

Pour faire un "cmd1 | cmd2" suivi d'un test sur le retour de cmd1, tu peux écrire :
cmd1 | cmd2
[[ $PIPESTATUS[0] == 0 ]] || echo "cmd1 a echoué"

> Quand je met des mots dans la barre d'adresse il fait un "jai de la
> chance" google.

about:config, et tu changes la clef nommée "keyword.URL" pour ce que tu veux (genre "http://www.google.com/search?ie=UTF-8&oe=UTF-8&q=" pour un google normal).

> la barre de recherche qui fait 10 caractères de long

Tu peux installer l'extension "Resize Search Box", qui permet... err, qui fait ce que son nom annonce quoi :
https://addons.mozilla.org/extensions/moreinfo.php?applicati(...)

> il déroule une liste de moteurs de recherche utilisables, facilement
> accessibles au clavier

Au cas où tu ne connaitrais pas le truc, dans la barre de recherche Firefox, Ctrl + Flèches Haut/Bas permet de choisir son moteur de recherche au clavier.


Bon, ouais, des clefs de config obscures, des extension pour des trucs triviaux, et des raccourcis clavier difficiles à deviner... Au bilan, si tu me dis que quand même Epiphany est vachement mieux fini, plus "polished", que Firefox, je ne pourrai qu'approuver. Je trouve que de se faire un Firefox à son goût prend un temps fou en recherche de doc et d'extensions. Maintenant, perso je l'utilise quand même (après bien des années sous Galeon, et non sans une certaine nostalgie) parceque certaines extensions sont vraiment géniales (conquery, greasemonkey, platypus, etc.) et sans équivalent à ma connaissance sous Epiphany ou Galeon... hélas.

En fonts bitmap, c'est aussi ce que j'obtenais. Ça dépend probablement de la version de gnome-terminal/vte/GTK/etc., de la taille du term, de la présence ou non d'une barre de défilement, tout ça quoi...

Perso, ce résultat de gnome-term 2x plus rapide que xterm, c'était avec :
- des terms de même taille (plein écran)
- sans barre de scroll
- police bitmap Lucida TypeWriter 9pt
- gnome-terminal-2.12.0 / GTK+-2.8.6 (et tout le bazar gnomesque dans ses dernières versions)
- xterm-204

Tiens, en parlant du choix du terminal idéal, un autre truc à prendre en compte, c'est ses capacités/fonctionnalités réelles. Perso c'est pas une question que je m'étais vraiment posée jusqu'à lire cette discussion, que j'avais trouvée vraiment très instructive :
http://thread.gmane.org/gmane.linux.gentoo.devel/30624
(note : ça vient de gentoo-dev@, mais la problématique n'a rien de spécifique à cette distrib')

Mouaif, ça mériterait d'être vérifié, mais comme ça intuitivement je dirais que ce genre de micro-optimisation, gcc les fait déjà tout seul comme un grand. C'est pas bien dur de détecter quand la valeur de l'expression n'est pas utilisée, et donc de ne pas la stocker même pour un i++.

Yo Colin,

Y'a le res/es/Makefile.am qui est passé à travers la p'tite modif' que je t'avais envoyée sur la 0.3 pour utiliser $(pkgdatadir) au lieu d'un chemin en dur. Enfin bref, patch :

--- res/es/Makefile.am
+++ res/es/Makefile.am
@@ -1,1 +1,1 @@
-bilobadir = $(prefix)/share/biloba/es
+bilobadir = $(pkgdatadir)/es

Je suis d'accord bien que des workaround y'en a tout plein et qu'ils sont pas franchement compliqués, mais voilà, ça me gonfle d'avoir à y penser. Je préfère voir le problème réglé une fois pour toute que de le contourner quotidiennement.

Bah... par exemple compiler un programme, ou bien même simplement se déplacer dans un gros fichier sous vim, c'est des utilisation "normales" d'un terminal, où ses performances font quand même une différence très perceptible.

Ça date un peu, mais à une époque j'avais benché "emerge" (le machin qui compile les paquets sous Gentoo), en mode normal d'une part (avec les commandes de compil', le listing des fichiers installés, etc.) et dans un mode silencieux d'autre part, qui cachait tous ces dumps superflus. Bah dans un gnome-terminal, la différence était vraiment loin d'être négligeable :
https://bugs.gentoo.org/attachment.cgi?id=23318

Mmmh... et un petit test de rxvt-unicode (urxvt) avec police TrueType en XFT met encore une claque à gnome-terminal + polices bitmap (~2x plus rapide, donc 16x plus que ce que j'utilisais à la base pour le même rendu). Bon bah je vais peut-être enfin changer de term finalement...

> peut être que gnome terminal va moins ramer

Suite au lien posté par GnunuX (merci), et au second billet sur le même blog [1], j'ai moi aussi comparé les vitesses de gnome-terminal et xterm. En gros, avec des terminaux en plein écran, et des polices de tailles similaires :
- gnome-terminal en TrueType est 4x plus lent que Xterm en bitmap ;
- gnome-terminal en bitmap est 2x plus rapide que Xterm en bitmap, et donc 8x plus rapide qu'en TrueType !

Le vainqueur haut la main de cette comparaison est donc bien gnome-terminal, et perso j'apprécie vraiment la nouvelle jeunesse que lui confèrent les polices bitmap, même si mes yeux regrettent un peu sa douceur baveuse d'antan.

Bon, ça c'est pour le point de vue utilisateur. Maintenant, du côté code, j'ai l'impression que la lenteur de gnome-terminal en TrueType n'est en fait pas encore bien comprise : McEs accuse plutôt XFT (ce qui semblait effectivement logique quand on lit les tests de son premier billet), mais quelqu'un lui à répondu que Konsole en TrueType, avec XFT aussi donc mais via Qt, ne souffrait pas de ces lenteur lui. Mystère donc...


[1] http://mces.blogspot.com/2005/10/behdads-pango-roadmap.html

Quand sysprof-1.0 a été annoncé sur LKML, il y a eu une petite discussion sur ses mérites par rapport à oprofile :
http://thread.gmane.org/gmane.linux.kernel/333049
Ce qui en ressort en gros, c'est que :
- niveau kernel-space, le module sysprof est redondant par rapport à celui d'oprofile, et semble plutôt avoir été écrit parceque son auteur sous-estimait oprofile ou le connaissait mal.
- la redondance sur cette partie n'est somme toute pas bien grave vu qu'il s'agit de qlqs centaines de lignes de code au plus.
- par contre, beaucoup de gens voudraient pouvoir utiliser la GUI de sysprof avec leur module de profiling habituel (oprofile). C'est vraiment cet outil d'analyse qui semble faire l'intérêt de sysprof.

> Sur mon pc poussif, xmms est la seule appli qui donne l'impression
> d'apparraite avant que j'ai fini mon double clic sur l'icone de mon
> fichier mp3.

C'est peut-être vrai sur un desktop utilisant déjà d'autres applis Gtk-1.2.x, mais sinon j'ai des doutes (charger tout un toolkit pour une seule appli, c'est toujours du gâchi, et ça se sent particulièrement sur une machine un peu poussive).

En fait, je pense que la façon la plus réactive d'ouvrir des mp3 par double-click, c'est de les balancer via mpc à un mpd qui tournerait déjà en arrière plan. Et en un peu moins rustique, un client mpd graphique (gmpc ou glurp pour les desktops Gtk-2, ou kmp pour les desktops Qt), ça doit pas mal se défendre aussi.

..., tes deux scripts s'exécutent dans des environnement indépendants, des nouveaux processus /bin/sh, donc ce que l'un exporte n'affecte pas l'environnement du shell qui l'appelle, et est oublié avant que l'autre ne soit exécuté. Tu peux le vérifier en faisant "shell1 ; shell2" sur ta ligne de commande d'ailleurs.

Si tu ne peux pas fusionner ces scripts (genre faire en sorte que shell2 soit plutôt appelé depuis shell1), alors il faut trouver autre chose qu'une variable d'environnement pour qu'ils communiquent. Genre un fichier temporaire, ou bien des E/S standard avec un pipe entre les deux. Ou bien alors il faut te débrouiller pour que la variable arrive dans l'environnement du shell qui est leur parent à tous les deux, dans ce genre là :

--- shell1:
#!/bin/sh
chaine=chemin/que/je/veux
echo "export chaine='${chaine}'"

--- Utilisation:
eval $(shell1) ; shell2

> lorsque je clique au centre de la barre hosrizontale, je m'attends
> instinctivement à ce que la lecture reprenne au milieu du film.

Ah ouais, je vois ce que tu veux dire, ça se défend. Mais en même temps, avancer par crans plutôt que de sauter direct à la position cliquée, c'est le comportement "normal" des sliders Gnome/GTK. Donc je suppose que c'est volontaire, enfin ça semble cohérent avec le reste du bureau. Perso je me rends compte que j'ai plutôt l'habitude de faire un drag du curseur, donc j'avais jamais trop fait gaffe en fait.

> Heu, comment dire, je préfère une interface pour une petite modif
> de ce genre.

J'avoue que je m'en doutais un peu :)
Mais bon, faut voir qu'une interface pour configurer tout ça, c'est forcement énorme et incompréhensible pour l'utilisateur moyen (cf. celle de xine-ui). Or la config automatique semble bien marcher et est probablement bien suffisante pour au moins 95% des utilisateurs, donc y'a pas trop de raison d'en exposer plus, enfin pas dans l'optique de Gnome en tout cas. Laisser la bidouille aux seuls bidouilleurs, c'est un peu un principe... D'autant que là, ça ne servirait qu'un des deux backend, qui n'est même pas celui par défaut.

> Cool, je connaissais pas.

Bon ceci dit, ce plugin n'existe je crois que depuis la version 1.2 (celle de Gnome-2.12 - il me semble qu'avant, il y avait quand même un truc qui faisait ouvrir le flux un totem "normal" avec toute ça GUI, mais rien pour le lire direct dans la page), et reste assez basique. Personnellement, je trouve mplayerplug-in plus fonctionnel (notament, j'aime bien les possibilités de copier l'URL et d'enregistrer le flux), donc en fait le plugin Totem je l'utilise pas.

> À quoi ça sert un « panel » ?

C'est un peu comme un dock, mais qui ne supposerait pas que tous les éléments sont des carrés de 64x64. Sous Gnome, ça sert d'égailleur de bord d'écran, dans lequel on range son horlge et son poisson. Sous KDE, ça sert à rien parcequ'il n'y a pas de poisson et que l'horloge est trop laide.

> pas de gestion de playlist

http://www.gnome.org/~davyd/gnome-2-12/images/totem-sidebar.png(...)

Ah oui, non, zut, tu n'en veux pas toi justement, c'est ça ? Bon enfin bref, donc oui, y'en a une dans Totem. Je suppose que c'est parceque c'est aussi le lecteur audio sous Gnome, donc dans ce cadre là elle doit servir (mais perso je l'utilise que pour de la vidéo, donc bof...).

> pas de gestion de playlist

http://www.gnome.org/~davyd/gnome-2-12/images/totem-sidebar.png(...)

> une barre horizontale qui marche

chémoissamarch (enfin, pour les fichiers correctement indexés quoi, mais disons pareil que dans xine)

> l'intégralité de la config de xine accessible

~/.gnome2/totem_config est un fichier de conf Xine complet (quant à ceux qui utilisent le backend GStreamer, bah la config est celle globale accessible depuis les préférences de Gnome)

> la relation entre epiphany et totem, ça marche comment déja ?

Via le plugin Totem, qui marche dans tous les browsers gecko.
http://www.gnome.org/~davyd/gnome-2-12/images/totem-mozilla.png(...)

Et "showkey" (dans une vraie console, pas dans un xterm), il dit qqch avec ces touches ?

> Dis... on parle bien Run Length Encoding, là ?

Oui. Les principes généraux ont l'air classique en effet. Après, je trouve pas de docs de référence d'Apple, et c'est pas la même variante que celle de MS, tout ça quoi...
Si t'es curieux, tu peux retrouver la doc citée par le code de FFmpeg ici :
http://web.archive.org/web/20031018231355/www.pcisys.net/~melanson/(...)
(doc par l'auteur du code et réciproquement d'ailleurs)

...y'a eu aussi ce post récemment qui résume bien la démarche à suivre :
http://linuxfr.org/comments/632497.html#632497(...)