/* Topic des codeurs couche-tard [4] */

Pylades · Le 26/04/2011, à 00:42

ArkSeth a écrit :

[…]
– Logiciel de choix de fonds d'écran, compatible avec Compiz (via dbus, donc seulement si Compiz est lancé) et Window Maker.
[…]

Mauvaise approche. Le fond d'écran, c'est indépendant du WM, de D-Bus et compagnie ; et ça se gère très bien avec hsetroot.

ArkSeth a écrit :

[…] En python 2, je ne sais pas si c'est compatible avec python 3.

Ce n'est assurément pas compatible avec Python 3, mais là n'est pas la question. Python 2 ou Python 3, ça ne regarde que le dev.

Elzen · Le 26/04/2011, à 01:12

Pylade a écrit :

Mauvaise approche. Le fond d'écran, c'est indépendant du WM, de D-Bus et compagnie ; et ça se gère très bien avec hsetroot.

Mon programme est avant tout prévu pour Touhy, qui n'utilise ni hsetroot, ni aucun autre logiciel externe, mais qui fait ça directement en PyGTK, de manière indépendante du WM (pas sûr que ça marche pour la fausse transparence, ceci dit).
Néanmoins, les gestionnaires de fenêtres Compiz et Window Maker proposent tous deux une gestion native des fonds d'écrans, et donc comme ce n'était pas trop compliqué, j'ai fais en sorte en plus que mon programme permette optionnellement d'utiliser leurs réglages spécifiques, pour le cas où l'utilisateur préférerait utiliser la gestion native de son WM plutôt que mon daemon.

D'ailleurs, pour Compiz, je crois bien qu'à moins de passer par une fenêtre de gestion du bureau, le seul moyen de changer les fonds d'écrans effectivement affichés est de passer par sa gestion interne, ce qui veut dire soit aller bidouiller manuellement son fichier de conf', soit utiliser dbus.

Dernière modification par ArkSeth (Le 26/04/2011, à 01:26)

cm-t · Le 26/04/2011, à 01:23

'Nuit;

Pylades · Le 26/04/2011, à 02:11

Ben ouais, mais ce que le gens ne semblent pas disposé à comprendre, c'est qu'un daemon pour le font d'écran, c'est très largement overkill ; et n'a pas de raison d'être.

Il n'y a que chez Openbox qu'on voit une approche raisonnable, et c'est bien dommage…

samυncle · Le 26/04/2011, à 02:34

.

Pylades · Le 26/04/2011, à 03:07

Compteur du TdCCT · Le 26/04/2011, à 07:42

Scores totaux, depuis le début :

1) 3120    nesthib
2) 2893    samuncle
3) 2491    Pylade
4) 1986    Кຼزດ
5) 1675+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1526    cm-t
7) 1112    :mad: ✰ :бешеный: ✰ :mad:
8) 858    helly
9) 844    \\Ouranos//
10) 659    gnuuat
11) 559    Lagierl
12) 525    tshirtman
13) 354    Rolinh
14) 287    The Uploader
15) 231    Kanor
16) 212    nathéo
17) 196    Askelon
18) 145    :!pakman
19) 121    ǤƦƯƝƬ
20) 93    petifrancais
21) 91    kamui57
22) 78    edge_one
22) 78    pierguiard
24) 70    gulp
25) 39    Le Rouge
26) 37    ilagas
27) 32    sakul
27) 32    xapantu
29) 30    keny
30) 26    gustare
30) 26    d10g3n
32) 25    GentooUser
32) 25    Morgiver
34) 24    ไ୦บเઢ'
34) 24    Steap
36) 20    CROWD
37) 18    Ph3nix_
38) 16    kouskous
39) 15    timsy
40) 12    stratoboy
40) 12    sailing
42) 11    alexises
42) 11    Crocoii
44) 10    Toineo
44) 10    NutMotion
44) 10    pseudovingtcinqcaracteres
44) 10    pfriedZ
44) 10    CasseTaTele
44) 10    Zeibux
44) 10    na kraïou
51) 8    Mornagest
52) 7    Vista
53) 6    ubuntlin
53) 6    asma.geek
55) 5    tendances-tdct
55) 5    kinouchou
57) 4    danychou56
57) 4    Neros
57) 4    Biaise
57) 4    totoflute
57) 4    pinballyoda ㋛
57) 4    NLS le pingouin
57) 4    ceric
57) 4    Dice-Man
65) 3    Revan26914
65) 3    raspouillas
67) 2    SoJaS
68) 1    geenux

Répartition Posts/heure

Compteur du TdCCT · Le 26/04/2011, à 07:42

Scores de la période en cours :

1) 200    nesthib
2) 192    samuncle
3) 160    Pylade
4) 111    cm-t
5) 94    Кຼزດ
6) 87    :mad: ✰ :бешеный: ✰ :mad:
7) 47    Rolinh
8) 40    nathéo
9) 37    tshirtman
10) 33    :!pakman
11) 32    \\Ouranos//
12) 30    The Uploader
13) 23    grim7reaper
14) 20    sakul
15) 10    helly
15) 10    na kraïou
17) 5    kamui57
18) 4    Dice-Man
19) 3    raspouillas
20) 2    kouskous
20) 2    xapantu

The Uploader · Le 26/04/2011, à 09:55

Pylade a écrit :

Ben ouais, mais ce que le gens ne semblent pas disposé à comprendre, c'est qu'un daemon pour le font d'écran, c'est très largement overkill ; et n'a pas de raison d'être.

Il n'y a que chez Openbox qu'on voit une approche raisonnable, et c'est bien dommage…

Hum, pour Xfce, xfdesktop n'est pas un démon, et ne s'occupe pas que du fond d'écran..

Elzen · Le 26/04/2011, à 11:37

Pylade a écrit :

Ben ouais, mais ce que le gens ne semblent pas disposé à comprendre, c'est qu'un daemon pour le font d'écran, c'est très largement overkill ; et n'a pas de raison d'être.

Il n'y a que chez Openbox qu'on voit une approche raisonnable, et c'est bien dommage…

Pas tout compris…

Déjà, je ne sais pas ce qu'est censé vouloir signifier overkill, mais surtout : dans ton post précédent, tu dis que la gestion du fond d'écran doit être indépendante du gestionnaire de fenêtres, dans celui-ci, tu dis qu'un daemon n'a pas de raison d'être, et que seul Openbox (qui est, je le rappelle, un gestionnaire de fenêtres) a une approche raisonnable. Ne détecterais-je pas comme une légère contradiction ?

Je vois trois solutions possibles pour gérer le fond d'écran :
– Soit une fenêtre de gestion de bureau, comme celle de Nautilus, ou celle de PCManFM, ou bien XfDesktop, ou bien le machin équivalent dans KDE, ou autres. Ce qui semble assez inutilement lourd quand la seule fonction de cette fenêtre est de tracer le fond d'écran, sans afficher d'icônes sur le bureau comme le font les gestionnaires de bureaux sus-cités.
– Soit un logiciel qui n'affiche aucune fenêtre spécifique mais se contente de repeindre la « fenêtre racine ». Seulement, dans ce cas, si on veut un arrière-plan différent par bureau, il faut bien que ce logiciel tourne en tâche de fond pour recommencer à peindre à chaque fois que l'utilisateur change de bureau, c'est ce que j'appelle un daemon.
– Soit que le gestionnaire de fenêtres s'en charge, ce qui me paraît être le cas le plus propre, étant donné que c'est également le gestionnaire de fenêtres qui se charge de gérer les multibureaux, et qu'il est donc le plus apte à provoquer l'action de repeindre en cas de changement.

Seulement, tous les gestionnaires de fenêtres ne proposent pas cette option, et l'un des objectifs de Touhy est de ne pas être dépendant d'un gestionnaire de fenêtres particulier.
Il m'apparaît donc naturel de proposer les deux autres approches : gestionnaire de bureau pour ceux qui veulent une fenêtre (avec ou sans icônes, après tout, chacun est juge), et daemon pour ceux qui veulent juste un changement de fond d'écran, sans fenêtre par dessus.
Cependant, pour le cas où les utilisateurs disposeraient d'un gestionnaire de fenêtres lançant lui-même la manip, et rendant donc inutile le fait de faire tourner un logiciel supplémentaire pour ça, je préfère également proposer, dans ma fenêtre de configuration, la possibilité de modifier également la configuration du gestionnaire de fenêtres, juste au cas où.
(Dans le même ordre d'idée, d'ailleurs, mon daemon permet également de modifier dynamiquement les configurations de Nautilus et de XfDesktop pour laisser l'utilisateur garder son gestionnaire de bureau habituel, tout en profitant de l'option « un fond d'écran par bureau » quand même. Mais c'est un peu lourd, comme façon de faire, je trouve).

Franchement, si c'est pas le bon comportement, j'veux bien qu'on m'explique où je fais erreur

(Et sinon, j'aimerais bien savoir aussi quelle est l'approche raisonnable d'Openbox : la dernière fois que j'ai regardé, Openbox n'avait pas l'air du tout de gérer les fonds d'écrans, comme la plupart des autres gestionnaires de fenêtres. C'est même au départ pour Openbox que j'ai commencé à créer ledit daemon, avant de le garder quand j'ai changé de gestionnaire de fenêtres)

Dernière modification par ArkSeth (Le 26/04/2011, à 11:41)

The Uploader · Le 26/04/2011, à 11:52

Tu me semble un brin aller vers le "tout configurable" (pas vraiment pour le moment, mais le point de rupture est proche). Attention, car au bout d'un moment, ce n'est plus gérable du tout point de vue code, même en étant très orienté introspection.

Dernière modification par The Uploader (Le 26/04/2011, à 11:53)

Elzen · Le 26/04/2011, à 12:09

Oh non, tout configurable, 'faut pas exagérer ^^

Pour les quelques points sus-cités, le répertoire de configurations (~/.config/touhy/) contient quatre fichiers et quatre répertoires :
– Un fichier pour la liste des fonds d'écrans.
– Un fichier pour la liste des icônes du gestionnaire de bureaux.
– Un fichier pour la liste des comportements en fonction des fenêtres.
– Un fichier pour la liste des boutons à afficher dans la zone contenant le SysTray.
– Un répertoire pour stocker d'autres « thèmes » de fond d'écran pour en changer plus vite.
– Un répertoire pour stocker les définitions de « docks » sur le bureau (c'était trop compliqué de tout mettre dans le fichier précédent).
– Un répertoire contenant les menus personnalisés pouvant éventuellement être affichés dans certains cas.
– Un répertoire contenant des fichiers gtkrc pour éventuellement changer le thème de certaines applis, qui est expérimental et quasiment pas utilisé.

Plus quelques options passées au démarrage des programmes qui ne sont pas mémorisées. Et t'en fais pas, j'm'efforce de garder du code que j'peux gérer ^^
J'veux fournir autant d'options que possibles pour que les utilisateurs puissent s'y retrouver, mais fournir un truc qui marche passe pour moi en priorité. D'autant que si un utilisateur avec des notions de programmations veut changer un truc, il peut.
D'ailleurs y a plein de trucs qui restent en dur, parce que même si je voulais, je ne saurais pas comment les rendre réglables.

Dernière modification par ArkSeth (Le 26/04/2011, à 12:14)

Pylades · Le 26/04/2011, à 13:34

ArkSeth a écrit :

Pylade a écrit :
Ben ouais, mais ce que le gens ne semblent pas disposé à comprendre, c'est qu'un daemon pour le font d'écran, c'est très largement overkill ; et n'a pas de raison d'être.

Il n'y a que chez Openbox qu'on voit une approche raisonnable, et c'est bien dommage…
Pas tout compris…
Déjà, je ne sais pas ce qu'est censé vouloir signifier overkill, mais surtout : dans ton post précédent, tu dis que la gestion du fond d'écran doit être indépendante du gestionnaire de fenêtres, dans celui-ci, tu dis qu'un daemon n'a pas de raison d'être, et que seul Openbox (qui est, je le rappelle, un gestionnaire de fenêtres) a une approche raisonnable. Ne détecterais-je pas comme une légère contradiction ?
[…]

Non, pas du tout.
Openbox, gestionnaire de fenêtres, sait très bien que son rôle n'est pas d'aller changer le fond d'écran. Donc il ne l'implémente pas lui même, mais dans un fichier de configuration :

# Set a background color
BG=""
if which hsetroot >/dev/null; then
    BG=hsetroot
else
    if which esetroot >/dev/null; then
    BG=esetroot
    else
    if which xsetroot >/dev/null; then
        BG=xsetroot
    fi
    fi
fi
test -z $BG || $BG -solid "#303030"

Là, il te conseille sur la méthode propre à mettre en œuvre. C'est grâce à ça que j'ai découvert hsetroot et compris que la plupart des gens gaspillaient des ressources comme pas permis avec le fond d'écran alors que c'est très simple.

ArkSeth a écrit :

[…]
Seulement, tous les gestionnaires de fenêtres ne proposent pas cette option, et l'un des objectifs de Touhy est de ne pas être dépendant d'un gestionnaire de fenêtres particulier.

Ah, ouais effectivement… C'est vrai que tu veux pouvoir bosser avec n'importe quel WM… dans ce cas-là je te donne raison.

ArkSeth a écrit :

Il m'apparaît donc naturel de proposer les deux autres approches : gestionnaire de bureau pour ceux qui veulent une fenêtre (avec ou sans icônes, après tout, chacun est juge), et daemon pour ceux qui veulent juste un changement de fond d'écran, sans fenêtre par dessus.
Cependant, pour le cas où les utilisateurs disposeraient d'un gestionnaire de fenêtres lançant lui-même la manip, et rendant donc inutile le fait de faire tourner un logiciel supplémentaire pour ça, je préfère également proposer, dans ma fenêtre de configuration, la possibilité de modifier également la configuration du gestionnaire de fenêtres, juste au cas où.
[…]

Ouais, je ne pense pas qu'on puisse trouver mieux comme comportement, dans ton cas. Au passage, je suis intéressé par ton gestionnaire de bureau, s'il est bien élevé et qu'il ne repeint pas le fond d'écran si on ne lui demande pas.

Elzen · Le 26/04/2011, à 17:23

Pylade a écrit :

Openbox, gestionnaire de fenêtres, sait très bien que son rôle n'est pas d'aller changer le fond d'écran.

Je maintiens que, le gestionnaire de fenêtres ayant pour tâche de gérer le nombre et le fonctionnement des multibureaux, ainsi que les éventuels effets d'animation et compagnie, il peut tout-à-fait lui revenir d'avoir, sinon à tracer lui-même le fond d'écran, au moins à appeler de façon automatisée un logiciel ayant pour tâche de le faire.
Tout dépend ensuite si l'on envisage un gestionnaire de fenêtres « complet » type Enlightenment ou Window Maker (le gestionnaire de fenêtre fonctionne comme un environnement « tout en un », en fournissant tout ce dont l'utilisateur a besoin pour avoir un bureau en état de marche), ou bien un gestionnaire de fenêtres « minimaliste » (qui est conçu pour être utilisé avec plein d'autres outils autour en permanence).

Pylade a écrit :

Au passage, je suis intéressé par ton gestionnaire de bureau, s'il est bien élevé et qu'il ne repeint pas le fond d'écran si on ne lui demande pas.

Eh bien, il s'agit d'une fenêtre non-transparente qui s'affiche à l'arrière-plan, qui cache entièrement la fenêtre racine, et qui, par voie de conséquence, affiche une image (ou au moins une couleur) qu'on peut qualifier de « fond d'écran ». Mais il ne touche pas lui-même à la fenêtre racine ni à l'image utilisée pour la pseudo-transparence, en tout cas.

Pylades · Le 26/04/2011, à 20:53

ArkSeth a écrit :

Pylade a écrit :
Openbox, gestionnaire de fenêtres, sait très bien que son rôle n'est pas d'aller changer le fond d'écran.
Je maintiens que, le gestionnaire de fenêtres ayant pour tâche de gérer le nombre et le fonctionnement des multibureaux, ainsi que les éventuels effets d'animation et compagnie, il peut tout-à-fait lui revenir d'avoir, sinon à tracer lui-même le fond d'écran, au moins à appeler de façon automatisée un logiciel ayant pour tâche de le faire.

Ouais, un système un peu comme les autocommandes de Vim ça pourrait être bien ; mais sinon intégrer directement dans le WM la gestion du fond d'écran c'est aussi ridicule que d'intégrer des tâches diverses allant du programme professionnel spécialisé au logiciel de mise à jour dans le navigateur Web, non-conforme aux normes de préférence.

ArkSeth a écrit :

Tout dépend ensuite si l'on envisage un gestionnaire de fenêtres « complet » type Enlightenment ou Window Maker (le gestionnaire de fenêtre fonctionne comme un environnement « tout en un », en fournissant tout ce dont l'utilisateur a besoin pour avoir un bureau en état de marche), ou bien un gestionnaire de fenêtres « minimaliste » (qui est conçu pour être utilisé avec plein d'autres outils autour en permanence).

Window Maker, je ne le connais pas, mais Enlightenment (et tous cas E17) c'est plus un DE, mais version monolithique et bloated. Donc pas un bon exemple.

ArkSeth a écrit :

Pylade a écrit :
Au passage, je suis intéressé par ton gestionnaire de bureau, s'il est bien élevé et qu'il ne repeint pas le fond d'écran si on ne lui demande pas.
Eh bien, il s'agit d'une fenêtre non-transparente qui s'affiche à l'arrière-plan, qui cache entièrement la fenêtre racine, et qui, par voie de conséquence, affiche une image (ou au moins une couleur) qu'on peut qualifier de « fond d'écran ». Mais il ne touche pas lui-même à la fenêtre racine ni à l'image utilisée pour la pseudo-transparence, en tout cas.

Dommage. T'as pas un lien vers une page d'accueil, de la doc et le code, quand même ?

sweetly · Le 26/04/2011, à 21:55

@pylade : juste une question, qui me taraude depuis un moment, à propos de ta signature.

Any if-statement is a goto

Ma question est : peut-on écrire un "if-statement" sans le "if" ? Autrement dit, le if est-il une forme algorithmique irréductible ?

Кຼزດ · Le 26/04/2011, à 22:21

Bon allez…

tshirtman · Le 26/04/2011, à 22:52

sweetly a écrit :

@pylade : juste une question, qui me taraude depuis un moment, à propos de ta signature.
Any if-statement is a goto
Ma question est : peut-on écrire un "if-statement" sans le "if" ? Autrement dit, le if est-il une forme algorithmique irréductible ?

on peut les écrire avec des or…

statement or function();

est équivalent à:
if not statement
→ function();

ou avec and:

statement and function();

est équivalent à:
if statement
→ function();

bon, ça suppose que la machine optimise les opérations de ce type, au lieu d'évaluer les deux cotés de l'opérande, avant d'évaluer l'opération complète.

Dernière modification par tshirtman (Le 26/04/2011, à 22:54)

sweetly · Le 26/04/2011, à 23:01

tshirtman a écrit :

sweetly a écrit :
@pylade : juste une question, qui me taraude depuis un moment, à propos de ta signature.
Any if-statement is a goto
Ma question est : peut-on écrire un "if-statement" sans le "if" ? Autrement dit, le if est-il une forme algorithmique irréductible ?
on peut les écrire avec des or…
statement or function();
est équivalent à:
if not statement
→ function();
ou avec and:
statement and function();
est équivalent à:
if statement
→ function();
bon, ça suppose que la machine optimise les opérations de ce type, au lieu d'évaluer les deux cotés de l'opérande, avant d'évaluer l'opération complète.

Ok, j'ai pas été super clair. J'étais ok sur le fait qu'on puisse écrire des if avec des opérateurs logiques, de toute manière, on sait pas faire autrement de l'algorithmique. Mais juste à haut niveau (pas au niveau langage de prog, juste algo vs implé électronique), j'ai pris la citation de Torvalds comme pouvant dire : "on peut écrire un if avec des goto". Je voulais savoir si c'était possible (parce que je ne vois pas comment) ou non.

Sir Na Kraïou · Le 26/04/2011, à 23:01

/part

tshirtman · Le 26/04/2011, à 23:03

@sweetly: je pense que torvalds se réfère à l'assembleur, ou un "if" est transformé en "comparaison + jump if not equal"

sweetly · Le 26/04/2011, à 23:05

tshirtman a écrit :

@sweetly: je pense que torvalds se réfère à l'assembleur, ou un "if" est transformé en "comparaison + jump if not equal"

Ok. Du coup, if est irréductible, dans ce cas. (Logiquement linguistiquement parlant). Merci

The Uploader · Le 26/04/2011, à 23:06

RoR pawa! http://api.rubyonrails.org/classes/Acti … ation.html

Dernière modification par The Uploader (Le 26/04/2011, à 23:08)

Elzen · Le 26/04/2011, à 23:24

Pylade a écrit :

Dommage. T'as pas un lien vers une page d'accueil, de la doc et le code, quand même ?

Si tu vois un moyen de gérer des icônes sur le bureau sans y foutre une fenêtre qui ait son propre arrière-plan, j'veux bien que tu m'expliques comment (Bien sûr, on pourrait foutre du shape, ou de la pseudo-transparence, ou encore utiliser du composing, afin que cette fenêtre de fond d'écran récupère automatiquement le fond affecté à la fenêtre racine, mais ça me semble terriblement lourd pour pas grand chose, quand le principe d'une fenêtre de gestion de bureau est précisément de masquer la fenêtre racine. Ou alors il faudrait faire ça avec une fenêtre par composant, ce qui serait encore plus lourdingue).

Pour répondre à ta question, j'ai pas encore releasé, mais j'espère faire ça d'ici pas trop trop longtemps.

Sinon, j'essayais de jouer un peu avec les xprop, mais j'avais pas compris aussi bien que ça, en fait : apparemment, la propriété strut (de même que « partial strut » qui en fait lui ressemble beaucoup) empêche toutes les fenêtres du bureau d'être maximisées dans la zone en question, y compris la fenêtre présentant cette propriété.
J'pensais que ça lui réservait la zone et qu'elle pouvait s'y maximiser tranquille, mais même pas…

Du coup, à part les démaximiser et changer manuellement leurs géométries, vous verriez un moyen de faire en sorte que deux fenêtres occupent chacune une moitié de l'écran ?

Dernière modification par ArkSeth (Le 26/04/2011, à 23:26)

The Uploader · Le 26/04/2011, à 23:28

Si tu vois un moyen de gérer des icônes sur le bureau sans y foutre une fenêtre qui ait son propre arrière-plan, j'veux bien que tu m'expliques comment

J'ai peur de un peu mal comprendre ton problème, mais tu pourrais voir du côté du code de Xfdesktop : http://archive.xfce.org/src/xfce/xfdesktop/4.8/

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1501 Le 26/04/2011, à 00:42

Re : /* Topic des codeurs couche-tard [4] */

#1502 Le 26/04/2011, à 01:12

Re : /* Topic des codeurs couche-tard [4] */

#1503 Le 26/04/2011, à 01:23

Re : /* Topic des codeurs couche-tard [4] */

#1504 Le 26/04/2011, à 02:11

Re : /* Topic des codeurs couche-tard [4] */

#1505 Le 26/04/2011, à 02:34

Re : /* Topic des codeurs couche-tard [4] */

#1506 Le 26/04/2011, à 03:07

Re : /* Topic des codeurs couche-tard [4] */

#1507 Le 26/04/2011, à 07:42

Re : /* Topic des codeurs couche-tard [4] */

#1508 Le 26/04/2011, à 07:42

Re : /* Topic des codeurs couche-tard [4] */

#1509 Le 26/04/2011, à 09:55

Re : /* Topic des codeurs couche-tard [4] */

#1510 Le 26/04/2011, à 11:37

Re : /* Topic des codeurs couche-tard [4] */

#1511 Le 26/04/2011, à 11:52

Re : /* Topic des codeurs couche-tard [4] */

#1512 Le 26/04/2011, à 12:09

Re : /* Topic des codeurs couche-tard [4] */

#1513 Le 26/04/2011, à 13:34

Re : /* Topic des codeurs couche-tard [4] */

#1514 Le 26/04/2011, à 17:23

Re : /* Topic des codeurs couche-tard [4] */

#1515 Le 26/04/2011, à 20:53

Re : /* Topic des codeurs couche-tard [4] */

#1516 Le 26/04/2011, à 21:55

Re : /* Topic des codeurs couche-tard [4] */

#1517 Le 26/04/2011, à 22:21

Re : /* Topic des codeurs couche-tard [4] */

#1518 Le 26/04/2011, à 22:52

Re : /* Topic des codeurs couche-tard [4] */

#1519 Le 26/04/2011, à 23:01

Re : /* Topic des codeurs couche-tard [4] */

#1520 Le 26/04/2011, à 23:01

Re : /* Topic des codeurs couche-tard [4] */

#1521 Le 26/04/2011, à 23:03

Re : /* Topic des codeurs couche-tard [4] */

#1522 Le 26/04/2011, à 23:05

Re : /* Topic des codeurs couche-tard [4] */

#1523 Le 26/04/2011, à 23:06

Re : /* Topic des codeurs couche-tard [4] */

#1524 Le 26/04/2011, à 23:24

Re : /* Topic des codeurs couche-tard [4] */

#1525 Le 26/04/2011, à 23:28

Re : /* Topic des codeurs couche-tard [4] */

Pied de page des forums