Kekun a écrit 637 commentaires

Quand j'ai voulu apprendre à programmer en autodidacte, je me suis cassé les dents sur le C : les pointeurs me perdaient.

Plus tard j'ai retenté le coup avec Python 3 et ça a été un succès, ça m'a permis dans un premier temps d'apprendre les bases de la programmation imprative (découpage en fonctions, affectation, typage…) pour ensuite retourner vers le C avec une compréhension d'une partie de ses concepts de base, me permettant de me concentrer sur d'autres points comme la gestion de la mémoire, la compilation…

Je suis ensuite retourné vers Python pour apprendre les bases de la POO, que j'ai ensuite pû approfondir avec Vala.

Je recommande fortement Python pour débuter.

Pas possible, elle est fermée, seul son éditeur peut l'ouvrir.

Je pense que je pourrai difficilement trouver plus proche que les 5 minutes à pied de cette année.

C'est un très faible prix pour nous pourrir l'espace visuel, auditif, et temporel.

Ça pollue les espaces vitaux : pollution sonore, pollution visuelle, papiers qui traînent…
Ça consomme des ressources : papier, encre, électricité, réseaux de communication, temps des publicitaires…
Et tout ça pour faire un lavage de cerveau souvent très efficace, ce qui est à mon sens le cœur du problème plus que l'aspect économique de la chose.

Je n'ai pas dit que c'était mon avis hein.

D'ailleurs je trouve ce concept aussi malin que débile et je n'arrive absolument pas à avoir un avis dessus.

Quand j'étais au lycée et qu'on parlait publicité en cours d'économie, mes profs disaient que le coût de la pub ne se répercuterais pas sur le prix final du produit car il serait absorbé par les bénéfices engendrés par les ventes supplémentaires qu'elle générerait.

C'est une vache mauve ?

Week-end ?

C'est hors sujet mais le mot "TITAN" m'a rappelé une démo récente pour Mega Drive faite par TiTAN : Overdrive.

Encore que ça n'est pas tant hors sujet que ça puisque je parle de demoscene et que cette machine a pas mal peuplé mon imaginaire d'adolescent (alors qu'elle était déjà enterrée depuis 10 ans) et c'est le hardware que j'ai le plus moddé… je me retrouve un peu dans ce que vous dites avec cette machine. =)

Puisqu'on est dans la nostalgie…

Il me semble que dès qu'on veut avoir affaire à une carte bancaire, on peut dire adieux au non-Windows faute de pilotes (ce qui explique le Windows Embeded dans les distributeurs).

Les banques devraient bien pouvoir taper du poing sur la table pour avoir des pilotes Linux mais là encore elles voudront du support à long terme, et remplaceront Microsoft pour Red Hat (par exemple). Pas sûr que les dirigeants y voient une grosse différence, et au moins ils connaissent Microsoft, c'est plus rassurant que "Red quoi ? Linux ? Ce truc de boutonneux dans une cave ?" (tout particulièrement dans les années 2000).

C'est couillon d'avoir une question qui incite au choix multiple quand le choix se fait avec un bouton d'option…

Parce qu'à une époque mon dada était de bidouiller des consoles de jeu, puis ça m'est passé, je bidouille libretro.

Justement, j'ai commencé à bosser sur l'intégration de libretro depuis une semaine (une partie du boulot se trouve sur ce dépôt).

Il manque beaucoup du code (qui mature un minimum chez moi) mais n'hésitez pas à rapporter des bugs !

Le projet avance lentement car je n'ai que peu de temps (je prend en partie sur le temps de mes cours pour le faire avancer). Pendant ce temps sebn continue de travailler sur Badnik en écrivant des test unitaires et en améliorant le design du code.

À terme, Badnik et retro-gobject se voudront être des briques de bases faciles à utiliser pour, respectivement, rechercher des jeux disponible et leur métadonnées, et y jouer. Prenant pour notre cas la forme de Video Games, une appli pour GNOME.

Du moment que c'est sous GNOME…

J'ai récement vu cette conférence sur l'évolution des systèmes de fichier sous Linux par des histogrames montrant l'évolution du nombre de lignes de code au fil du temps.

Les pics montrent les ajouts de fonctionnalitées et les barres plus petites des corrections.

Un détail intéressant est que les pics induisant ces ajouts de fonctionnalités ne sont pas forcément des pics augmentant le nombre de lignes de code mais parfois les diminuant significativement.

Parfois less is more.

Quand je dis qu'il est mort, il faut plus le voir comme une renaissance. =)

M'est avis que LXQt sera plus intéressant que ses deux ancêtres.

De même, j'aime énormément GNOME 3 et je prend toujours plus de plaisir à l'utiliser version après version.

C'est un bureau qui sait se faire oublier et m'aide à mieux m'organiser quand je travaille.
J'aime sa logique de simplicité et de sobriété, tout comme ses inspirations de Mac OS, Android et consorts.

Seulement je ne ressens pas le besoin de crier mon amour de ce bureau sur les toits, ni de dénigrer ses concurrents (j'utilise aussi LXDE par exemple).

C'est sans doute pour ça que tu en entends si peu de bien : les trolls font bien plus de bruit que les louanges ou les critiques constructives.

Razor Qt est mort, le projet a été fusionné à LXDE qui migre vers Qt.

D'ailleurs ils n'ont pas précisé si une connexion par câble wifi faisait parti de la configuration minimale.

Les Chromebook (enfin, du moins certains) ont quand même un avantage non négligeable pour les libristes pur souche : du Coreboot dans le beudou.

Leur vrai problème c'est la faible capacité de stockage, ce qui a du sens si on n'utilise que ChromeOS, mais si on préfère vivre sur la terre ferme que dans les nuage, on manque vite d'espace…

Le Chromebook Pixel pourrait me tenter (sous un autre OS, comme Fedora) en version 64 Go (et un peu plus ne serait pas du luxe).

VDPAU (1 rouge)
Enchanter : distribution

La distribution enchantée acquiert la célérité.

« Que les vidéos filent. »

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.

L'idée est de se baser sur des BDD en ligne déjà existantes et qui se sont stabilisées, et d'en récupérer les informations fondamentales.

C'est une bonne solution d'avoir plusieurs sources parmis lesquelles figurent les émulateurs, le gestionnaire de paquet et les .desktop.

Les émulateurs ne fournissent pas la moindre information, tout ce qu'ils ont, ils le trouvent soir dans les fichiers de jeu (autant dire dans rien du tout), soit dans des bases de données hors ligne (comme ce que je compte mettre en place).

Il ne faut pas avoir de sources qui nécessitent un accès internet.

C'est précisément un de mes buts : me passer de l'accès à internet autant que possible en fournissant en local une partie des données dans les GameData.

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.

À quoi bon utiliser quelque chose de standard si je dois l'adapter derrière, et donc me priver de l'écosystème de ce standard ? Je ne suis pas contre utiliser un format particulier, mais ce qui compte avant tout ce n'est pas la forme mais la disponibilité des données en local.

Pourquoi AppData ne convient pas?

AppData ne prend pas des problématiques propres aux jeux comme le type de contrôleurs, le nombre d'utilisateurs, les modes de jeu (local, lan…)…

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

Seul un très faible nombre de jeux sont distribués avec un .desktop, je pense notamment aux jeux sur consoles (qui sont distribués sous forme de binaire de rom, d'image disque…) ou autres.

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, …

C'est la solution de facilité et c'est précisément ce que j'ai tenté de faire en premier lieu et j'ai malheureusement constaté que ça ne marche pas aussi bien que prévu.
GameData est une partie de la solution que je propose pour résoudre le problème d'obtention des données : ça permet de les distribuer avec l'application gérant les jeux.

Au sujet du build system, je te conseille plutôt CMake, ou n'importe quel outil autre que les GNU autotools archaïques.

Je jetterai un œil à CMake, j'ai essayé de comprendre Automake mais en vain jusque là…

Pour les front-end qui varient, c'est une excellente idée, mais c'est un peu comme pour les plug-in, ce n'est pas en en faisant qu'un que tu pourras avoir une interface ( logicielle ) définitive et fonctionnelle. Ce n'est pas que moi qui le dis, lorsque que je faisais des recherches à ce sujet, je suis tombé sur divers documents, dont un de google qui indiquait en gros que les interfaces de plug-in deviennent correctes à partir de 3 plug-in. Je gage que ce sera la même chose dans ton cas, bien qu'on puisse plutôt parler de plugout, puisque c'est le moteur (transmission-common) qui est le plugin d'une interface (transmission-gtk/cli/daemon/qt).
J'ai le même sentiment a propos des applications comme mpd, bien que le use case soit très différent.

J'en profiterai pour découvrir Qt d'autres environnements. =)

J'y ai pensé et j'ai cherché des règles et cas d'utilisation de sous éléments ou d'attributs, avant de pencher, je ne sais plus trop pourquoi, pour l'utilisation d'un sous élément… mais c'est vrai que ça serait certainement mieux en attribut, je change ça.

Merci pour ta remarque, c'est entre autre le genre de remarques sur la forme que j'espérais obtenir.
Bien sûr j'espère aussi des remarques sur le fond. =)