MCMic a écrit 972 commentaires

Wow merci des astuces, alt + f fonctionne dans fish et permet d'accepter la complétion proposée mot par mot, pour ne reprendre que le début.
ctrl+w/y fonctionne aussi.

Je préférerais quand même trouver un shell qui utilise ctrl + flèche droite/gauche pour se déplacer de mot en mot et ctrl + backspace ou suppr pour supprimer un mot comme c'est le cas dans les éditeurs de texte.

Hum, aucune idée, je n'ai jamais utilisé ces raccourcis.
ctrl+a est ma touche de commande tmux.
ctrl+e et alt+f ne font rien dans mon fish mais dans mon bash non plus, c'est censé faire quoi?

Les avantages que je vois à fish:

• La coloration et la complétion
• La recherche facile dans l'historique (je tape config puis flèche haut j'ai la dernière commande contenant config)
• Le tab bien géré (c'est faisable aussi dans zsh, mais dans zsh la config par défaut me plait pas celle de fish me convient), complétion qui fonctionne pour tout (sous Arch j'ai ça dans bash avec le paquet bash_completion, sous debian j'ai jamais réussi à avoir ne serait-ce que la complétion après sudo dans bash)
• Le raccourcis des paths je le trouve pas idiot (première lettre de chaque dossier sauf le dernier)
• Des petits détails soignés, genre début d'un mot puis tab m'indique les commandes possibles mais aussi leur description, exemple avec 'mo' : http://pastebin.archlinux.fr/477455
• le ** à la zsh (qui manque dans bash)
• un historique des cd, on peut naviguer dedans avec prevd, nextd et dirh permet de le voir
• ^ permet de rediriger stderr, à la manière de < et > pour stdin et stdout. (^ ^ fonctionne comme << et >>)

Ce qui est pas cool:

• Il a pas le même langage donc c'est dangereux de le mettre en shell par défaut (je l'ai juste mis comme shell tmux du coup)
  • Ce langage n'est pas un langage existant (ils auraient pu prendre python, php, perl, ruby, ou un sous-ensemble de l'un deux, ou que sais-je… mais non)
  • Dans ce langage les index de tableaux commencent à 1
• La configuration est pas bien pratique, ya pas un beau fichier de conf commenté à éditer, le truc de config web est pas pratique et marche pas toujours, donc pour l'instant chuis un peu dans le flou.
• Comme il lit pas .bashrc faut le traduire, export devient set -x, etc…
• Ya quelques reflexes à prendre, les fonctions au lieu des alias, set au lieu d'export, …

Bref, en clair il a de gros avantages sur bash, sur un zsh bien configuré c'est moins sûr.

Je suis récemment passé au shell fish.
Je m'y plais bien mais liquidprompt me manque. J'ai essayé oh-my-fish insipiré par oh-my-zsh et c'est loin d'égaler liquidprompt.
J'ai vu ce début de ré-écriture de liquidprompt pour fish : https://github.com/HarnoRanaivo/liquidprompt/tree/fish mais malheureusement il ne fonctionne pas chez moi.
C'est fort dommage car j'adore son approche avec les fonctions "lp_enable", "lp_disable" pour paramétrer facilement les fonctionnalités sans taper directement dans le code comme il faut le faire pour oh-my-fish :-/

Tu as déjà un paquet Debian et Ubuntu, ça coûte pas cher de le mettre en vente sur le store Canonical : http://developer.ubuntu.com/publish/apps/other-forms-of-submitting-apps/publish-a-commercial-app/

Je me rends pas du tout compte de ce qui est possible avec XBMC, on peut lancer des applications avec?

Mais effectivement c'est un peu l'idée coté interface, menu plein écran avec mozaique d'icône, et surtout jeux classés par catégories.
Une distribution gamer aurait aussi intérêt à proposer mumble et ce genre d'outils qui sont utilisés en périphérie des jeux.

Comme dit plus haut, un peu dommage de restreindre à LXDE. Étrange aussi d'écarter systemd.

Concernant LinuxConsole 2, peut-on en savoir plus?
L'idée est-elle de faire un liveCD ou bien une vraie distribution faite pour être installée et se servir de son PC pour jouer?
Quels sont les axes étudiés? (packaging des jeux, menu utilisable à la manette, accent sur le support des matériels graphiques… ?)

Ta base ne sera jamais complète, et la mise à jour des infos en fonction des sorties/mise à jour de jeu est un travail de titan, qui ne sera très probablement pas fait suffisamment régulièrement.

C'est une bonne solution d'avoir plusieurs sources parmis lesquelles figurent les émulateurs, le gestionnaire de paquet et les .desktop.
Il ne faut pas avoir de sources qui nécessitent un accès internet.
Tu peux éventuellement avoir ton système en complément pour ajouter les jeux manquants ou les infos qui ne sont pas données par les autres sources, mais ce serait mieux de prendre un standard comme le .desktop et l'étendre pour y mettre les données spécifiques aux jeux.

Je n'ai pas compris, quel problème cherche tu à résoudre avec ton nouveau format qui n'est pas résolu par l'existant?

Pourquoi AppData ne convient pas?
Pourquoi ne pas directement prendre les infos dans les .desktop des jeux?

Ne serait-il pas possible d'avoir un truc générique avec des modules pour les différentes sources d'info, qui permettrait de prendre l'info dans les paquets quand le jeu est un paquet, dans son fichier .desktop quand il en a un, via un émulateur pour les jeux concernés, dans un truc spécifique si besoin et qu'il est présent, …

On veut des photos des cupcakes!

Le dual boot pose déjà problème du fait que mon disque est petit

Ça je peux comprendre, c'est un éternel problème…

Utiliser cette machine avec un autre os, qui lui va forcement moins bien, ça me fend le coeur.

Ça m'étonne, je pensais pas que la différence soit si flagrante, le matos Apple étant très répandu je pensais qu'il faisait parti des trucs bien supportés par les distributions. (et accessoirement Apple fait du bon matos donc si on a les moyens c'est pas le pire des choix pour y faire touner un GNU/Linux)

Pour l'histoire des partitions je pensais que Mac OSX savait lire les différents formats, contrairement à Windows, il faut croire que non…

Je ne saisi pas pourquoi il te faut une nouvelle machine pour changer d'OS?
Quels problèmes t'ont posés le dual-boot?

Et, - j'ose! - si le dual-boot ne te convient pas, pourquoi ne pas simplement remplacer ton OS par un autre? (Perso j'étais sous Windows avant, j'ai commencé par un dual-boot par frilosité mais au bout d'un an et quelques je me suis rendu compte que je bootais toujours sur le même OS donc j'ai viré l'autre)

Alors…

J'ai pas fini puzzle moppet, loin s'en faut, j'ai pas la patience pour ce genre de jeu, ya un niveau sur lequel j'ai buté trop de fois et j'ai lâché l'affaire.
Je l'ai cité parce que je trouve qu'il exploite bien la 3D sans en faire des tonnes. Et un soin a été apporté au graphisme et au coté «mignon et attachant» de l'univers, ce qui ne veut pas dire que c'est totalement réussi.
Je vois ce que tu veux dire par «un peu vide». Mais j'aime bien les jeux au style simple, difficile de trouver le juste milieu pour pas aller non plus dans la surcharge.
Je ne saurais pas te répondre sur le scénario je me souviens plus et je l'ai pas fini, c'est pas impossible que ce soit qu'une vague excuse à l'enchaînement des niveaux. C'est pas le genre de chose qui me gênent, j'aime pas les longs scénarios, typiquement dans Bastion ça m'a vite ennuyé au point d'arrêter, là j'ai commencé à jouer à hammerfight c'est un peu pareil, je me fiche de savoir sur qui je tape et pourquoi, j'ai envie de jouer pas de suivre une histoire. Je crois qu'on a pas les mêmes goûts en jeu-vidéo :-)
J'aime beaucoup plus des univers bien plus abstraits, type braid, ou encore Limbo. On a pas tous les détails, on sait pas trop ce qu'il se passe et pourquoi, mais il y a une ambiance spécifique.
Pour en finir au sujet de Puzzle Moppet, suite à la libération du code le dépôt que j'ai lié dans mon commentaire contient un fork libre (ou plutôt une continuation, on a l'autorisation de l'auteur pour conserver le nom), et ils ont remplacés les textures et certains sons par du libre parce que les licences allaient pas, mais du coup ça a été fait un peu à la va vite, si vous vous sentez de contribuer des données cohérentes, n'hésitez pas :-)

Tu ne trouves pas nos créatures aussi attachantes si ce n'est plus ? =3

J'aime bien Ned mais faut revoir l'animation de marche.
J'aime beaucoup moins le professeur pokita.

J'ose à peine y croire. Nous voilà en plein hs, finissons en là.

Le HS n'existe pas sur linuxfr. Chaque commentaire ouvre un nouveau fil sur un nouveau sujet :-P

Comme l'on dit les autres, dans mon esprit GIMP était fait pour la retouche photo et pas le dessin… Mais j'ai récemment constaté que certains dessinaient avec et s'en sortait pas mal : http://linuxfr.org/news/financement-participatif-de-dessin-symetrique-dans-gimp (Mais faut dire que là la personne a un dev sous la main pour adapter GIMP à son usage)

C'est dommage de ne pas avoir de moyen de discussion publique autour du projet (forum, irc, tribune, mailing list, …)

http://fr.wikipedia.org/wiki/Sokoban

Pour atteindre l'escalier vers le niveau supérieur, a priori.

Difficile de ne pas débuter mon commentaire par un état de l'art sur ce qui existe en sokoban libre.
J'y connais pas grand chose dans le domaine mais quand je lis "l'apparition de la 3D, du tactile et une narration justifiant les actions du joueur différente mais pas extraordinaire. Sympathique, mais pas plus attachant ni plus pérenne. La mécanique restait la même, et le mode de jeu unique.", je pense quand même à Puzzle Moppet , libéré il y a quelques temps, qui a au moins le mérite d'avoir essayé, sinon réussi, à rendre le sokoban 3D pertinent et attachant: http://garnetgames.com/puzzlemoppet/ (version libre: https://bitbucket.org/Knitter/puzzlemoppet/overview )

En voyant parmi les dessins proposés, celui qui ressemble à un screenshot de jeu, je pense tout de suite à I Have No Tomatoes qui a le même genre de vue, sauf que c'est un jeu 3D et type bomberman. Hé bien j'ai jamais bu blairer ce jeu, et j'aime pas cette vue de coté qui n'apporte pas grand chose et fait perdre pas mal de place en concentrant le rendu du tableau au centre de l'écran.
Alors je comprends bien qu'un rendu 2D de haut est pas très attrayant et que cette vue permet aussi de faire des choses plus sympa coté dessin mais ça me parait pas optimal, peut-être en mettant la caméra un peu plus haut ça ira mieux, mais ça fait ptet un angle trop compliqué à dessiner…

En dehors de ça, il serait bien de préciser ce que vous visez pour avoir une idée des technologies qui seront utilisées: Est-ce un jeu pour PC et/ou mobile? Un jeu natif et/ou en navigateur?

Si j'avais plein de temps je participerais volontiers, surtout que ce serait l'occasion de faire joujou avec ces histoires d'entités/composant/systèmes en C++11 et de tester emscripten pour une version web, mais comme souvent le temps me manque…

Toujours pas d'avancée non plus coté support LDAP, ça laisse vraiment à désirer…

Pour moi ça répond à un besoin, les jeux sont toujours la 5ème roue du carrosse dans les distributions…
Ils ont des besoins parfois spécifiques (notamment tout jeu en ligne a besoin d'être en rolling release sinon on peut plus jouer).

Ça fait longtemps que je suis étonné de l'absence d'une distribution orientée jeu-vidéo pour proposer une expérience agréable:
- Interface utilisable avec une manette de jeu
- Jeux mis à jour (C'est le seul truc que j'ai plus ou moins résolu, en utilisant AUR sous Arch on s'en sort pour être à jour y compris pour le non-libre, mais tout n'est pas encore packagé hélas…)
- Menu avec classement par catégorie correct (sans dec, c'est qui qui choisit les catégories des jeux chez Debian/Ubuntu (ou Gnome, j'ai toujours pas compris qui gérait les sous-catégories)? C'est l'anarchie impossible de s'y retrouver)
- Attention particulière sur les drivers vidéos et leur packaging, le support des manettes de jeu, présence d'outils pour configurer ça de manière pratique, et j'en passe… (Un outil pour passer son clavier en qwerty facilement dans le cas des jeux mal fichus! Un gestionnaire de sauvegardes unifié!…)

Les carrés de FreeSiege pourraient convenir : http://freesiege.sourceforge.net/screens/screen0.png (les images sont là : https://github.com/MCMic/freesiege/tree/master/sprites magic.png, wood.png, steel.png, fire.png)
Ça vient de glest, yen a d'autres dispos juste à colorer : http://opengameart.org/content/magic-and-mechanic-in-game-interface-icons

Après avoir étudié les différentes possibilités (français, anglais, latin, grec ancien, esperanto… :p ) il nous est apparu qu’un nom anglais serait le plus universellement reconnu. En somme, OpenClassrooms sera davantage compris à l’international que si on l’avait appelé, disons… ClassesOuvertes.

Ils ont envisagés les différentes possibilités, c'est l'anglais qui a été retenu.

Il me semble que ça ne sert à rien de se dire qu'on va utiliser plusieurs rendus quand on n'en utilisera qu'un seul.

Je trouve ça quand même dommage, pouvoir passer à un rendu console ou 3D facilement, c'est chouette :)

Au contraire, SFML gère très bien la traduction entre coordonnées de l'univers et coordonnées de l'écran grâce à une View. Dans l'exemple, j'ai fait la traduction moi-même mais c'était pour l'exemple. Après, on peut déléguer ça à SFML (il suffit juste de définir la View qui va bien).

Justement, ça fait pour moi partie du rendu. Et je pensais que c'était pas simple de séparer les deux actions en SFML mais ça fait quelque temps que j'y ai pas touché et tu as l'air sûr de toi donc ça doit être faisable.
Juste que ça me parait overkill de séparer le rendu en deux systèmes, j'ai du mal à voir ce que ça apporte.

Quelques remarques sur l'exemple du tutoriel avec les balles rebondissantes:

• Tu bases tout sur SFML, ce que je trouve un peu dommage, pour moi un des avantages de ce paradigme c'est de séparer proprement le rendu du reste, pour pouvoir faire plusieurs implémentations du système rendu (Tu pourrais donc avoir une version SDL, une version SFML et une version console des mêmes balles rebondissantes en recodant uniquement le rendu).
• Je saisi pas bien ce besoin d'avoir un composant avec les coordonnés réels, pour moi c'est interne au rendu, et donc le système rendu devrait directement travailler avec le composant position. En plus en SFML ce genre de chose se gère avec un viewport, ce que tu vas avoir du mal à faire si tu sépare rendu et traduction des coordonnés.
• Comme dit plus haut c'est triste cet entier à mettre à la main dans toutes les classes :-(

Un serveur owncloud n'est pas un serveur FTP?
Après quelques recherches il semble que ce n'est effectivement pas forcément le cas.

C'est donc le support webdav qu'il faudrait pour correctement s'interfacer avec owncloud? (Oui, confondre les logiciels et les protocoles, ça m'agace, votre site firefox fonctionne-t-il également avec opera?)

Avec OpenDungeons, ça fait 2 :-P (cf http://linuxfr.org/news/occupez-votre-ete-contribuez-a-un-jeu-libre )

comme c'est un surensemble de SDL2, au pire, je peux revenir à SDL2 et redévelopper les bouts qui manquent

Qu'appelle-tu un sur-ensemble de SDL2? La SFML est basée sur OpenGL, pas sur SDL.