Bah on aura vraiment l'air cons alors, si on arrête le nucléaire avant de trouver des solutions…
L'avantage, c'est qu'on verra les anti-nucléaire râler à la télé, tout simplement parce qu'il n'y aura plus assez de jus pour l'allumer.. Ah, pour le coup, c'est peut-être aussi une bonne solution pour rehausser le niveau intellectuel moyen ça…
Je ne voulais pas trop parler des icônes, vu que je n'utilise pas de file browser, mais c'est bizarre cette histoire, généralement juste installer le thème recommandé (par dpkg) fait que les icônes marchent*.
Donc qu'il y ait besoin d'un démon pour ça, me semble tout sauf normal.
Après, tu utilises manifestement un outil gnome/KDE, qui ne sont pas des DE que je qualifierai de réellement modulaire, c'est peut-être lié.
Pour les profils de couleur ICC, je n'ai aucune idée de comment gérer, je sais juste vaguement à quoi ça sert, et encore, j'en suis pas sûr :D
*: Tiens, d'ailleurs, je devrais peut-être suggérer la création d'un paquet virtuel pour les paquets d'icônes à Debian, ça pourrait être intéressant.
Je voudrais donc que cairo-dock me lance nemo --no-desktop. Mais comment faire cela en donnant un fichier .desktop? Dois-je créer mon propre .desktop?
Je sais pas quelle serait la méthode propre, mais perso je m'embêterai pas: un bon vieux script qui appelle le bon programme avec les bons arguments, et voila.
Aussi n'existe-t-il pas un logiciel de configuration "générique" (= non lié à un desktop en particulier, pour configurer des choses communes, comme ces préfs XDG)?
Parce que la plupart des gens qui bossent sur XDG doivent avoir un bureau complet, j'imagine.
J'ai contourné ce problème avec gnome-settings-daemon & dans mon autostart. Ça ne lance pas un desktop GNOME complet, mais la partie qu'il me fallait. Pas sûr que ça lance pas aussi quelques trucs dont je veux pas, par contre.
Quand je cherche des applications stand-alone, perso je regarde plus du côté de LXDE que des autres DE. Ils ont tendance à tirer nettement moins de dépendances…
C'est pas un complètement peu contradictoire avec la phrase suivante ? :
Ben non. Je trouve que les UI des sites web et autres webapp sont bien loin de celles que j'ai avec les applications desktop de ma machine.
Ce qui n'empêche pas que changer la techno utilisée pour l'IHM ne devrait pas changer des masses de code si l'architecture est bien foutue.
Ah OK ! je croyais qu'on on parlait d'IHM, au temps pour moi.
Justement. MPD n'a pas d'IHM, ou plutôt, on peut considérer (je dit bien "peut" et pas "doit", ainsi que "considérer" et non "constater") que ce logiciel à de nombreuses IHM: ario, ncmpcpp, etc.
Je sais que techniquement, il ne s'agit pas d'IHM mais d'applications séparées, mais elles remplissent malgré tout la fonctionnalité d'IHM (certains en font plus, cependant).
Trop de…
Bruit.
En espérant avoir enlevé les zones d'ombre de mon précédent message.
C'est pour ça que j'ai arrêté les documentations qui paraphrasent le nom et le type de la variable. Ca sert juste a rien dans 95% des cas.
Je préfère documenter les pré/post conditions, les invariants et les throw.
Bref, le contrat, et ce qui est fait si le contrat n'est pas respecté.
Je pense vraiment que c'est la meilleure approche, ça m'évite de paraphraser mon code, et donc la quantité de merde commentaires diminue drastiquement, tout en fournissant des informations bien plus pertinentes (même si il est vrai qu'on les retrouve dans le code, mais c'est parfois éparpillé dans les 20-30 lignes de fonction…)
Quant aux return… bah c'est aussi rarement utile que les paramètres dans un langage qui supporte les exceptions, puisque dans ce cas on peut se permettre de ne pas s'en servir pour indique si y'a eu ratage ou pas.
Et même comme ça, je ne commente pas les fonctions triviales (genre moins de 5 lignes). Bon, après, j'ai une très nette préférence pour les langages ayant un typage fort, donc je pense que ça aide pas mal. Quand on passe un const &uint8_t, on sait déjà beaucoup de choses sur le paramètre, même sans son nom.
Et si j'ai besoin de flags, plutôt que d'utiliser un moche int, je lui mets au moins un typedef, et en général je suis plutôt du genre à vouloir utiliser des bitfield. Plutôt que d'utiliser des #define dont on ne sait jamais trop où, quand et comment ils sont définis, et ne seront jamais vérifiés par le compilo.
Il n'y a pas un port C++ pour GTK? GTKmm ou un truc du genre?
Enfin, le truc qui me chagrine le plus avec Qt à l'heure actuelle, c'est qu'il ne s'agit pas juste d'une lib pour faire des IHM, plutôt d'un framework complet. Suis pas fan d'utiliser un seul outil énorme pour tout faire, même si j'en comprend les intérêts par rapport à utiliser une foultitude de lib spécialisées.
Le souci, c'est qu'il ne semble pas y avoir des masses de lib spécialisées pour faire des IHM, qui soient portables, légères, et qui ne tentent (je n'ai pas dit que Qt, Gtk, ou quoique ce soit force, attention, je parle de tentation ) pas le dev d'utiliser des classes non standard.
Je parle ici des strings et divers conteneurs, et pas pour un souci de perf, mais de garder un code le plus standard possible, de sorte a ce que, si, un jour, par malheur, il faille changer l'interface, qu'on aie pas une trop grosse dépendance à une seule lib.
En gros, si boost intégrait une lib graphique, ce serait à peu près l'esprit que j'aimerai (même si, je sais, boost et les versions c'est pas toujours top il paraît. Je n'utilise pas depuis assez d'années pour avoir eu des problèmes avec ça cependant).
PS: je ne dis pas non plus que c'est simple à faire, surtout pour ce qui est de l'intégration à l'environnement natif
PPS: il y a toujours des raisons majeures de choisir Gtk au lieu de Qt: combine au moins deux de ces éléments: l'expertise des gens qui travaillent, l'existence d'une base de code existante, le manque de main d'oeuvre.
Enfin, personnellement, je ne pense pas que les technos basées sur HTML soient déjà mûres, et faites pour, avoir des IHM aussi performantes que ce qu'on à sur le bureau.
Cela dit, je suis plutôt d'accord sur certaines de tes interventions: si c'est bien codé, ça ne devrait pas changer grand chose que l'IHM soit en gtk, motif, Qt ou html, les fonctionnalités seront les mêmes.
A ce niveau, le logiciel qui m'impressionne le plus, c'est clairement mpd. Ca, c'est un logiciel portable, et qui ne risque pas d'avoir de problèmes d'intégrations à cause d'une stupide lib graphiques qui ne sera de toutes façons plus à la mode dans 10 ans. Et ça, ça vaut pour HTML et sa tétrachiée d'ajouts pour lui faire faire ce que ce n'est pas censé faire de base (aka: des logiciels s'exécutant côté client) aussi.
On en fait trop autour de ce truc.
On parie que je peux citer au moins 1 nom de personne qui voudrait les voir ouvrir leurs sources? :p
/me se félicite de n'avoir point usé de nom précédemment
Si c'est des tests génériques pour des logiciels, non je fournis pas ça avec crossroad. Il ne s'agit que d'un système de compilation, pas un environnement de test.
Ah non! Y'a assez d'outil qui font le café comme ça, merci :)
S'il te manque une dépendance que j'ai pas vue, donc pas citée, tu auras une erreur, et tu pourras me la remonter. :-)
A moins que tu ne fasses tout via le réseau et n'aie pas le droit d'exécuter des binaires non validés sur la machine qui t'intéresse, tu as oublié une solution simple: la framakey.
Je sais pas si c'est encore maintenu, mais ça semble régler ton problème de base, à savoir la portabilité de tes documents.
Pour le reste, le HTML vs LaTeX, je me suis fait mon opinion. Je n'ai jamais vraiment supporté les suites offices: ces outils sont trop lourds, trop complexes, bref, peu adaptés à mes besoins personnels.
Donc, à une époque, j'utilisais HTML pour faire des documents texte avec un minimum de présentation, grâce à amaya (et un peu notepad++). La syntaxe est XML-based, donc lourde comme tu l'as dis, ça demande un apprentissage conséquent ou du boulot pour faire un sommaire ( apprentissage conséquent pour avoir des trucs automatiques, que je n'ai pour être franc jamais été motivé pour faire) et c'est, au final, loin d'être proprement portable ( en fonction du navigateur ou de la taille d'écran, le rendu est différent, ce qui n'est pas forcément souhaitable, et ce, surtout pour une impression! )
J'ai toujours lorgné sur LaTeX, mais j'étais limité par windows… ben oui, télécharger 700MiO pour faire du traitement de texte, en sachant qu'il faudrait en plus apprendre un langage… flemme quoi. Surtout que, c'est quoi cette "pléthore" de distributions ( du point de vue du windowsien que j'étais, je parle hein )? Que choisir?
Cependant, j'ai fini par franchir le pas, de même que j'ai fini par passer à Debian. Conséquence, installation 'achement moins casse couille ( aptitude install textlive-recommended et zou, roulez jeunesse ), chopage d'un exemple qui trainasse sur le net, et en 10 min j'avais compris comment ça marche.
Le résultat: des documents écrits bien plus vite, LaTeX n'ayant pas cette cochonnerie de syntaxe icsémélienne, plus maintenable, pour la même raison, et qui m'affranchit définitivement d'avoir à choisir mes couleurs quand j'écris un rapport ( ça tombe bien, j'ai jamais aimé l'art plastique ), après compilation on à du pdf, qui s'affiche partout pareil, et comble de bonheur, pas de logiciels hyper lourds!
Que demande le peuple? Du HTML? Bah, il suffit de générer du HTML dans ce cas… je sais que c'est faisable, même si j'ai jamais testé.
Pour moi, LaTeX est ce qui se fait de mieux, même si je ne le maîtrise pas (mais je maîtrise pas plus HTML ou word de toute façon). Le document est vraiment portable, parce qu'on peut le modifier sur n'importe quelle machine ( un simple éditeur de texte fait l'affaire ) et supporte une tonne de formats différents en sortie.
Ah, mon canard me chuchote d'ailleurs qu'on peut générer des odt à partir de latex… mais idem, je n'ai jamais testé.
Possible, toujours est-il que la, il ne fait pas la moindre pub pour une lib qui serait dev par apple ou ms, il indique seulement qu'il est possible avec gtk de se passer de X sous mac.
En fin de compte, si je comprend bien, les raisons du switch, c'est que GTK supporte mal les plate formes mobiles, mais surtout que ça nécessite soit un port expérimental, soit Xorg sous mac OS X. Il parle aussi d'un problème d'intégration, mais je n'ai pas eu l'impression qu'il s'agisse du principal souci.
Plutôt d'excellentes raisons pour le coup, bien que ça ne soit pas spécialement surprenant (j'ai l'impression que mac OS est une plate-forme assez pénible… la plupart des rapports de bug spécifiques à un OS que je vois des projets open source semblent y être liés… ou alors il n'y a personne sur mac qui contribue, je sais pas).
Autrement dit: rien à voir avec la défense des produits Apple ou Microsoft.
Ben non, y'a intel aussi, même s'il est vrai que ça me semble restreint en terme de 3D…
Mais bon, il faut aussi admettre: je vois pas mal de courriels défiler au sujet de problèmes avec des drivers proprio ATI… alors que ceux de NVidia ne semblent poser des soucis techniques que rarement. Le seul souci technique que j'ai eu avec le pilote NVidia, c'est quand j'ai voulu passer du .run de NVidia au paquet Debian, j'ai du merder un truc et j'ai un peu bidouillé en root pour retrouver une machine avec l'accélération 3D fonctionnelle. A par ça, 0 problèmes.
Donc, même si on peut les conspuer parce qu'ils ne libèrent par leur source ( en même temps, c'est leur droit ), je ne peux que constater les efforts qu'ils font pour que ça marche proprement sur ma Debian. Parfois je me dis que je changerai, puis je regarde mes mails et ça me passe, au moins avec nvidia je peux utiliser un pilote proprio qui marche bien en espérant qu'un jour nouveau parvienne à être assez efficace sur la 3D.
Attention tout de même, la taille des int n'est pas définie dans le standard. J'ai souvenir (je suis pourtant pas bien vieux) d'une époque et d'un compilateur ou un int était sur 2 octets… depuis que j'ai constaté la différence, je n'utilise tout simplement plus int: short et long sont un poil plus fiables.
Et encore mieux: les (u)intXX_t pour une donnée de taille bien fixée et évidente. Si on veut un truc pour la vitesse (questions d'alignement je suppose), il existe des variantes "fast" dont le nombre de bits minimum est garanti, également.
Ceux-la, depuis que je les ai découverts, je ne m'en lasse plus (pas les variantes fast, ça rajoute trop de frappe clavier à mon goût pour les utiliser partout…). En plus, il y a des macros qui permettent d'avoir les valeurs minimum et maximum de ces types, dans le même fichier… Que demander de plus?
Il reste les float & double, mais bon, ceux-la je ne les utilise de toute façon qu'en dernier recours. Pour la plupart des traitements, les unsigned suffisent amplement.
A chaque fois que je profile, je me rends compte que si l'application est lente c'est à cause du dev et pas du matos.
Pas besoin de ça, il suffit de se souvenir que, 15 ans en arrière, ces machines faisaient tourner des windows 98 avec des word ou des duke nukem 3D sans souci, entres autres. Maintenant, il m'arrive d'aller pêcher des jeux dans le repo debian, graphiquement bien moins poussés, et ils rament… je sais que mon matos est pas excellent non plus, mais bon, faut pas pousser, pour la 2D un proc moderne ( minimum 2 fois plus de coeurs et cadencé 2x plus vite, pour un proc à bas prix ) suffit largement. Sans parler de la RAM…
Cela dis, tu as raison, je devrais aussi profiler plus. Souci: j'ai jamais pris le temps de regarder comment valgrind marche ( je l'ai déjà testé, mais je suis noyé dans un flot d'informations plus ou moins pertinentes… peut-être que s'il y avait moyen de limiter la profondeur au programme lui-même et/ou de faire des graphes ce serait plus simple? Je sais pas. )
Pour être honnête, je document aussi les pré-conditions, post-conditions et invariants qui ne sont pas évidents et/ou des fonctions publiques. Histoire de pas aller fouiner dans le code lui-même à chaque fois…
Mais j'appelle pas trop ça du commentaire, plutôt de la doc, même si c'est fait via des commentaires doxygen.
dbus sert pourtant à beaucoup d'applications. Avoir un système de messages entre applications, c'est pas franchement révolutionnaire (les autres OS font pareil)
Bah, je n'ai rien contre lui. Sauf que je n'ai qu'une seule application qui semble en avoir besoin, donc l'intérêt à l'air quand même vachement limité ;)
Donc je l'ai désactivé, faute de ne pouvoir le désinstaller. Je n'ai noté aucune différence de fonctionnement.
ni honteux, hein. ;-)
Il n'est jamais honteux de rajouter une dépendance utile. Même s'il s'agit de systemd :p ( contre lequel je n'ai rien en particulier, l'idée de rendre les script d'init simples à maintenir et utilisables par un utilisateur à peu près normal m'est même très séduisante. )
Mais bien sûr, les corrections seront bien plus simples et minimes si tu as essayé d'être portable dès le début. Et peut-être même qu'il n'en aura aucune, qui sait?!
Il y en aura au moins une, j'ai une ligne qui empêche spécifiquement que ça marche sur windows en guise de todo :D
Cette fameuse ligne ( un throw dans un #ifdef WIN32 ) doit être remplacée par un mécanisme pour contrer le fait qu'il n'y a pas de /etc sous windows.
Je pense que je vais finir par me faire une lib pour les emplacements de fichiers de config ( en utilisant un fichier passé en param en 1er, puis fallback sur config user, et finalement sur config système ), d'ailleurs, ça me prendra 30 lignes et m'évitera de le faire dès que je veux gérer des config de façon portable et en prenant en compte les spec XDG…
Merci pour la faute de voc.
Ce n'était que pour avoir un truc négatif sur ton 'nal, fallait que je trouve un truc… En plus c'est une histoire de syntaxe sur ce coup, pas de voc :p
Sinon, pendant que j'y pense, si tu as une batterie de tests, je peux toujours voir ce que ça donne sur mes systèmes… Me connaissant, je ne serai pas surpris qu'il manque des dépendances dans ta description ( système lourdement allégé, si je suis puis dire )
J'ai toujours voulu tester la cross compilation, mais ai toujours préféré maintenir un projet code::blocks portable et rebooter, plutôt que de devoir penser par moi-même…
Et pile en ce moment je songeais à me remettre sur autorealm que j'ai juste complètement lâché depuis… pfff trop longtemps. Ton truc va me permettre de pouvoir enfin vérifier que ça marche réellement sous windows \o/ ( j'ai toujours gardé la portabilité à l'esprit, donc, en théorie il ne devrait y avoir aucun souci, mais… )
Donc, merci.
PS: et juste histoire d'avoir un truc négatif à dire, mon compilateur français bloque sur ce passage: " et prônes à l'erreur" et me suggère un remplacement par " et facilitant l'erreur", mais c'est vraiment juste pour faire chier :p
Tu sais, certains ont dit que le logiciel parfait n'est pas celui ou il n'y a plus rien à ajouter, mais celui ou il n'y a plus rien a enlever. Pour le coup, ça semble très proche de la perfection :p
Je dis sûrement une connerie (n'utilisant pas de DE ni de gestionnaire de connexion) mais je crois que systemd est une dépendance des truckKit.
C'est aussi une dépendance de dbus ( ça c'est sûr par contre, j'ai libsystemd-login0 installé à cause de dbus, ici… et dire que dbus ne me sers à rien… groumpf)
[^] # Re: Viellesse et consommation
Posté par freem . En réponse à la dépêche Donnez une seconde jeunesse à votre ordinosaure, le samedi 26 octobre 2013 à Draguignan. Évalué à 4.
Bah on aura vraiment l'air cons alors, si on arrête le nucléaire avant de trouver des solutions…
L'avantage, c'est qu'on verra les anti-nucléaire râler à la télé, tout simplement parce qu'il n'y aura plus assez de jus pour l'allumer.. Ah, pour le coup, c'est peut-être aussi une bonne solution pour rehausser le niveau intellectuel moyen ça…
[^] # Re: Qui sera le prochain ?
Posté par freem . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 1.
Gimp n'est pas un logiciel de dessin?
[^] # Re: Avec Compiz seul.
Posté par freem . En réponse à la dépêche Cairo-Dock 3.3 prêt à s'installer sur votre bureau !. Évalué à 1.
Je ne voulais pas trop parler des icônes, vu que je n'utilise pas de file browser, mais c'est bizarre cette histoire, généralement juste installer le thème recommandé (par dpkg) fait que les icônes marchent*.
Donc qu'il y ait besoin d'un démon pour ça, me semble tout sauf normal.
Après, tu utilises manifestement un outil gnome/KDE, qui ne sont pas des DE que je qualifierai de réellement modulaire, c'est peut-être lié.
Pour les profils de couleur ICC, je n'ai aucune idée de comment gérer, je sais juste vaguement à quoi ça sert, et encore, j'en suis pas sûr :D
*: Tiens, d'ailleurs, je devrais peut-être suggérer la création d'un paquet virtuel pour les paquets d'icônes à Debian, ça pourrait être intéressant.
[^] # Re: Avec Compiz seul.
Posté par freem . En réponse à la dépêche Cairo-Dock 3.3 prêt à s'installer sur votre bureau !. Évalué à 1.
Je sais pas quelle serait la méthode propre, mais perso je m'embêterai pas: un bon vieux script qui appelle le bon programme avec les bons arguments, et voila.
Parce que la plupart des gens qui bossent sur XDG doivent avoir un bureau complet, j'imagine.
Quand je cherche des applications stand-alone, perso je regarde plus du côté de LXDE que des autres DE. Ils ont tendance à tirer nettement moins de dépendances…
[^] # Re: HTML5
Posté par freem . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 2.
Ben non. Je trouve que les UI des sites web et autres webapp sont bien loin de celles que j'ai avec les applications desktop de ma machine.
Ce qui n'empêche pas que changer la techno utilisée pour l'IHM ne devrait pas changer des masses de code si l'architecture est bien foutue.
Justement. MPD n'a pas d'IHM, ou plutôt, on peut considérer (je dit bien "peut" et pas "doit", ainsi que "considérer" et non "constater") que ce logiciel à de nombreuses IHM: ario, ncmpcpp, etc.
Je sais que techniquement, il ne s'agit pas d'IHM mais d'applications séparées, mais elles remplissent malgré tout la fonctionnalité d'IHM (certains en font plus, cependant).
Bruit.
En espérant avoir enlevé les zones d'ombre de mon précédent message.
[^] # Re: La bonne question serait plutôt : Que commentez-vous ?
Posté par freem . En réponse au sondage Les commentaires et vous ? . Évalué à 2.
C'est pour ça que j'ai arrêté les documentations qui paraphrasent le nom et le type de la variable. Ca sert juste a rien dans 95% des cas.
Je préfère documenter les pré/post conditions, les invariants et les throw.
Bref, le contrat, et ce qui est fait si le contrat n'est pas respecté.
Je pense vraiment que c'est la meilleure approche, ça m'évite de paraphraser mon code, et donc la quantité de
merdecommentaires diminue drastiquement, tout en fournissant des informations bien plus pertinentes (même si il est vrai qu'on les retrouve dans le code, mais c'est parfois éparpillé dans les 20-30 lignes de fonction…)Quant aux return… bah c'est aussi rarement utile que les paramètres dans un langage qui supporte les exceptions, puisque dans ce cas on peut se permettre de ne pas s'en servir pour indique si y'a eu ratage ou pas.
Et même comme ça, je ne commente pas les fonctions triviales (genre moins de 5 lignes). Bon, après, j'ai une très nette préférence pour les langages ayant un typage fort, donc je pense que ça aide pas mal. Quand on passe un const &uint8_t, on sait déjà beaucoup de choses sur le paramètre, même sans son nom.
Et si j'ai besoin de flags, plutôt que d'utiliser un moche int, je lui mets au moins un typedef, et en général je suis plutôt du genre à vouloir utiliser des bitfield. Plutôt que d'utiliser des #define dont on ne sait jamais trop où, quand et comment ils sont définis, et ne seront jamais vérifiés par le compilo.
[^] # Re: Qui sera le prochain ?
Posté par freem . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 5. Dernière modification le 22 octobre 2013 à 15:52.
Je parlais bien évidemment du G de Gimp… Ca me semblait logique, puisque je répond à un message suggérant de renommer Gimp en Qimp. Bref.
Sinon, l'info est ici: http://www.gtk.org/
"GTK+, or the GIMP Toolkit, "
[^] # Re: bébé
Posté par freem . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 2. Dernière modification le 22 octobre 2013 à 14:46.
Il n'y a pas un port C++ pour GTK? GTKmm ou un truc du genre?
Enfin, le truc qui me chagrine le plus avec Qt à l'heure actuelle, c'est qu'il ne s'agit pas juste d'une lib pour faire des IHM, plutôt d'un framework complet. Suis pas fan d'utiliser un seul outil énorme pour tout faire, même si j'en comprend les intérêts par rapport à utiliser une foultitude de lib spécialisées.
Le souci, c'est qu'il ne semble pas y avoir des masses de lib spécialisées pour faire des IHM, qui soient portables, légères, et qui ne tentent (je n'ai pas dit que Qt, Gtk, ou quoique ce soit force, attention, je parle de tentation ) pas le dev d'utiliser des classes non standard.
Je parle ici des strings et divers conteneurs, et pas pour un souci de perf, mais de garder un code le plus standard possible, de sorte a ce que, si, un jour, par malheur, il faille changer l'interface, qu'on aie pas une trop grosse dépendance à une seule lib.
En gros, si boost intégrait une lib graphique, ce serait à peu près l'esprit que j'aimerai (même si, je sais, boost et les versions c'est pas toujours top il paraît. Je n'utilise pas depuis assez d'années pour avoir eu des problèmes avec ça cependant).
PS: je ne dis pas non plus que c'est simple à faire, surtout pour ce qui est de l'intégration à l'environnement natif
PPS: il y a toujours des raisons majeures de choisir Gtk au lieu de Qt: combine au moins deux de ces éléments: l'expertise des gens qui travaillent, l'existence d'une base de code existante, le manque de main d'oeuvre.
[^] # Re: Qui sera le prochain ?
Posté par freem . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 1.
Euh… le 'G' veut dire Gnu, hein, s'pas un acronyme récursif…
[^] # Re: HTML5
Posté par freem . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 4.
Bien ce que je pensais :)
Enfin, personnellement, je ne pense pas que les technos basées sur HTML soient déjà mûres, et faites pour, avoir des IHM aussi performantes que ce qu'on à sur le bureau.
Cela dit, je suis plutôt d'accord sur certaines de tes interventions: si c'est bien codé, ça ne devrait pas changer grand chose que l'IHM soit en gtk, motif, Qt ou html, les fonctionnalités seront les mêmes.
A ce niveau, le logiciel qui m'impressionne le plus, c'est clairement mpd. Ca, c'est un logiciel portable, et qui ne risque pas d'avoir de problèmes d'intégrations à cause d'une stupide lib graphiques qui ne sera de toutes façons plus à la mode dans 10 ans. Et ça, ça vaut pour HTML et sa tétrachiée d'ajouts pour lui faire faire ce que ce n'est pas censé faire de base (aka: des logiciels s'exécutant côté client) aussi.
On en fait trop autour de ce truc.
[^] # Re: Le monde à l'envers 2
Posté par freem . En réponse au journal Pilotes de cartes graphiques : le monde à l'envers. Évalué à 1.
On parie que je peux citer au moins 1 nom de personne qui voudrait les voir ouvrir leurs sources? :p
/me se félicite de n'avoir point usé de nom précédemment
[^] # Re: Intéressant
Posté par freem . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 1.
Ah non! Y'a assez d'outil qui font le café comme ça, merci :)
C'est bien mon intention.
# portable Libreoffice (ou openoffice, peu importe)
Posté par freem . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. Évalué à 3.
A moins que tu ne fasses tout via le réseau et n'aie pas le droit d'exécuter des binaires non validés sur la machine qui t'intéresse, tu as oublié une solution simple: la framakey.
Je sais pas si c'est encore maintenu, mais ça semble régler ton problème de base, à savoir la portabilité de tes documents.
Pour le reste, le HTML vs LaTeX, je me suis fait mon opinion. Je n'ai jamais vraiment supporté les suites offices: ces outils sont trop lourds, trop complexes, bref, peu adaptés à mes besoins personnels.
Donc, à une époque, j'utilisais HTML pour faire des documents texte avec un minimum de présentation, grâce à amaya (et un peu notepad++). La syntaxe est XML-based, donc lourde comme tu l'as dis, ça demande un apprentissage conséquent ou du boulot pour faire un sommaire ( apprentissage conséquent pour avoir des trucs automatiques, que je n'ai pour être franc jamais été motivé pour faire) et c'est, au final, loin d'être proprement portable ( en fonction du navigateur ou de la taille d'écran, le rendu est différent, ce qui n'est pas forcément souhaitable, et ce, surtout pour une impression! )
J'ai toujours lorgné sur LaTeX, mais j'étais limité par windows… ben oui, télécharger 700MiO pour faire du traitement de texte, en sachant qu'il faudrait en plus apprendre un langage… flemme quoi. Surtout que, c'est quoi cette "pléthore" de distributions ( du point de vue du windowsien que j'étais, je parle hein )? Que choisir?
Cependant, j'ai fini par franchir le pas, de même que j'ai fini par passer à Debian. Conséquence, installation 'achement moins casse couille ( aptitude install textlive-recommended et zou, roulez jeunesse ), chopage d'un exemple qui trainasse sur le net, et en 10 min j'avais compris comment ça marche.
Le résultat: des documents écrits bien plus vite, LaTeX n'ayant pas cette cochonnerie de syntaxe icsémélienne, plus maintenable, pour la même raison, et qui m'affranchit définitivement d'avoir à choisir mes couleurs quand j'écris un rapport ( ça tombe bien, j'ai jamais aimé l'art plastique ), après compilation on à du pdf, qui s'affiche partout pareil, et comble de bonheur, pas de logiciels hyper lourds!
Que demande le peuple? Du HTML? Bah, il suffit de générer du HTML dans ce cas… je sais que c'est faisable, même si j'ai jamais testé.
Pour moi, LaTeX est ce qui se fait de mieux, même si je ne le maîtrise pas (mais je maîtrise pas plus HTML ou word de toute façon). Le document est vraiment portable, parce qu'on peut le modifier sur n'importe quelle machine ( un simple éditeur de texte fait l'affaire ) et supporte une tonne de formats différents en sortie.
Ah, mon canard me chuchote d'ailleurs qu'on peut générer des odt à partir de latex… mais idem, je n'ai jamais testé.
[^] # Re: bébé
Posté par freem . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 4.
Possible, toujours est-il que la, il ne fait pas la moindre pub pour une lib qui serait dev par apple ou ms, il indique seulement qu'il est possible avec gtk de se passer de X sous mac.
En fin de compte, si je comprend bien, les raisons du switch, c'est que GTK supporte mal les plate formes mobiles, mais surtout que ça nécessite soit un port expérimental, soit Xorg sous mac OS X. Il parle aussi d'un problème d'intégration, mais je n'ai pas eu l'impression qu'il s'agisse du principal souci.
Plutôt d'excellentes raisons pour le coup, bien que ça ne soit pas spécialement surprenant (j'ai l'impression que mac OS est une plate-forme assez pénible… la plupart des rapports de bug spécifiques à un OS que je vois des projets open source semblent y être liés… ou alors il n'y a personne sur mac qui contribue, je sais pas).
Autrement dit: rien à voir avec la défense des produits Apple ou Microsoft.
[^] # Re: HTML5
Posté par freem . En réponse au journal C'est au tour de Wireshark de passer à Qt. Évalué à 6.
Ha ben merci, j'ai bien ri.
Cela dit, rassures-moi, c'était bien une blague?
[^] # Re: Le monde à l'envers 2
Posté par freem . En réponse au journal Pilotes de cartes graphiques : le monde à l'envers. Évalué à 6.
Ben non, y'a intel aussi, même s'il est vrai que ça me semble restreint en terme de 3D…
Mais bon, il faut aussi admettre: je vois pas mal de courriels défiler au sujet de problèmes avec des drivers proprio ATI… alors que ceux de NVidia ne semblent poser des soucis techniques que rarement. Le seul souci technique que j'ai eu avec le pilote NVidia, c'est quand j'ai voulu passer du .run de NVidia au paquet Debian, j'ai du merder un truc et j'ai un peu bidouillé en root pour retrouver une machine avec l'accélération 3D fonctionnelle. A par ça, 0 problèmes.
Donc, même si on peut les conspuer parce qu'ils ne libèrent par leur source ( en même temps, c'est leur droit ), je ne peux que constater les efforts qu'ils font pour que ça marche proprement sur ma Debian. Parfois je me dis que je changerai, puis je regarde mes mails et ça me passe, au moins avec nvidia je peux utiliser un pilote proprio qui marche bien en espérant qu'un jour nouveau parvienne à être assez efficace sur la 3D.
[^] # Re: 5 ans d'âge...
Posté par freem . En réponse à la dépêche Donnez une seconde jeunesse à votre ordinosaure, le samedi 26 octobre 2013 à Draguignan. Évalué à 2.
Attention tout de même, la taille des int n'est pas définie dans le standard. J'ai souvenir (je suis pourtant pas bien vieux) d'une époque et d'un compilateur ou un int était sur 2 octets… depuis que j'ai constaté la différence, je n'utilise tout simplement plus int: short et long sont un poil plus fiables.
Et encore mieux: les (u)intXX_t pour une donnée de taille bien fixée et évidente. Si on veut un truc pour la vitesse (questions d'alignement je suppose), il existe des variantes "fast" dont le nombre de bits minimum est garanti, également.
Ceux-la, depuis que je les ai découverts, je ne m'en lasse plus (pas les variantes fast, ça rajoute trop de frappe clavier à mon goût pour les utiliser partout…). En plus, il y a des macros qui permettent d'avoir les valeurs minimum et maximum de ces types, dans le même fichier… Que demander de plus?
Il reste les float & double, mais bon, ceux-la je ne les utilise de toute façon qu'en dernier recours. Pour la plupart des traitements, les unsigned suffisent amplement.
Pas besoin de ça, il suffit de se souvenir que, 15 ans en arrière, ces machines faisaient tourner des windows 98 avec des word ou des duke nukem 3D sans souci, entres autres. Maintenant, il m'arrive d'aller pêcher des jeux dans le repo debian, graphiquement bien moins poussés, et ils rament… je sais que mon matos est pas excellent non plus, mais bon, faut pas pousser, pour la 2D un proc moderne ( minimum 2 fois plus de coeurs et cadencé 2x plus vite, pour un proc à bas prix ) suffit largement. Sans parler de la RAM…
Cela dis, tu as raison, je devrais aussi profiler plus. Souci: j'ai jamais pris le temps de regarder comment valgrind marche ( je l'ai déjà testé, mais je suis noyé dans un flot d'informations plus ou moins pertinentes… peut-être que s'il y avait moyen de limiter la profondeur au programme lui-même et/ou de faire des graphes ce serait plus simple? Je sais pas. )
[^] # Re: Faut voir...
Posté par freem . En réponse au sondage Les commentaires et vous ? . Évalué à 3.
Pour être honnête, je document aussi les pré-conditions, post-conditions et invariants qui ne sont pas évidents et/ou des fonctions publiques. Histoire de pas aller fouiner dans le code lui-même à chaque fois…
Mais j'appelle pas trop ça du commentaire, plutôt de la doc, même si c'est fait via des commentaires doxygen.
[^] # Re: Je croyais qu'on pourrait se passer de systemd si on le voulait ....
Posté par freem . En réponse au journal Ayé c'te fois : GNOME 3.8 est dans Debian Sid (mais attention). Évalué à 1.
Ah ok, merci.
Bah, je n'ai rien contre lui. Sauf que je n'ai qu'une seule application qui semble en avoir besoin, donc l'intérêt à l'air quand même vachement limité ;)
Donc je l'ai désactivé, faute de ne pouvoir le désinstaller. Je n'ai noté aucune différence de fonctionnement.
Il n'est jamais honteux de rajouter une dépendance utile. Même s'il s'agit de systemd :p ( contre lequel je n'ai rien en particulier, l'idée de rendre les script d'init simples à maintenir et utilisables par un utilisateur à peu près normal m'est même très séduisante. )
[^] # Re: Intéressant
Posté par freem . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 1. Dernière modification le 22 octobre 2013 à 12:02.
Il y en aura au moins une, j'ai une ligne qui empêche spécifiquement que ça marche sur windows en guise de todo :D
Cette fameuse ligne ( un throw dans un #ifdef WIN32 ) doit être remplacée par un mécanisme pour contrer le fait qu'il n'y a pas de /etc sous windows.
Je pense que je vais finir par me faire une lib pour les emplacements de fichiers de config ( en utilisant un fichier passé en param en 1er, puis fallback sur config user, et finalement sur config système ), d'ailleurs, ça me prendra 30 lignes et m'évitera de le faire dès que je veux gérer des config de façon portable et en prenant en compte les spec XDG…
Ce n'était que pour avoir un truc négatif sur ton 'nal, fallait que je trouve un truc… En plus c'est une histoire de syntaxe sur ce coup, pas de voc :p
Sinon, pendant que j'y pense, si tu as une batterie de tests, je peux toujours voir ce que ça donne sur mes systèmes… Me connaissant, je ne serai pas surpris qu'il manque des dépendances dans ta description ( système lourdement allégé, si je suis puis dire )
# Faut voir...
Posté par freem . En réponse au sondage Les commentaires et vous ? . Évalué à 4.
Les noms de variable et de fonction, ça compte? :p
# Intéressant
Posté par freem . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 2.
J'ai toujours voulu tester la cross compilation, mais ai toujours préféré maintenir un projet code::blocks portable et rebooter, plutôt que de devoir penser par moi-même…
Et pile en ce moment je songeais à me remettre sur autorealm que j'ai juste complètement lâché depuis… pfff trop longtemps. Ton truc va me permettre de pouvoir enfin vérifier que ça marche réellement sous windows \o/ ( j'ai toujours gardé la portabilité à l'esprit, donc, en théorie il ne devrait y avoir aucun souci, mais… )
Donc, merci.
PS: et juste histoire d'avoir un truc négatif à dire, mon compilateur français bloque sur ce passage: " et prônes à l'erreur" et me suggère un remplacement par " et facilitant l'erreur", mais c'est vraiment juste pour faire chier :p
[^] # Re: GNOME est sur la bonne voie....
Posté par freem . En réponse au journal Ayé c'te fois : GNOME 3.8 est dans Debian Sid (mais attention). Évalué à 2.
Tu sais, certains ont dit que le logiciel parfait n'est pas celui ou il n'y a plus rien à ajouter, mais celui ou il n'y a plus rien a enlever. Pour le coup, ça semble très proche de la perfection :p
[^] # Re: Je croyais qu'on pourrait se passer de systemd si on le voulait ....
Posté par freem . En réponse au journal Ayé c'te fois : GNOME 3.8 est dans Debian Sid (mais attention). Évalué à 1.
Je dis sûrement une connerie (n'utilisant pas de DE ni de gestionnaire de connexion) mais je crois que systemd est une dépendance des truckKit.
C'est aussi une dépendance de dbus ( ça c'est sûr par contre, j'ai libsystemd-login0 installé à cause de dbus, ici… et dire que dbus ne me sers à rien… groumpf)
[^] # Re: DuckDuckGo
Posté par freem . En réponse au journal Osez votre propre moteur de recherche !. Évalué à 1.