Pour faire court: j'apprécie quand les outils que j'utilise ne sont pas liés les uns aux autres.
Je considère que si jamais je détecte un bug dans un tel outil, je peux le corriger.
Ça m'est d'ailleurs déjà arrivé, parce qu'un outil n'intégrant pas 10 000 fonctionnalités différentes, autrement suivant les principes du KISS, est bien plus simple à fixer.
Voila pourquoi je n'apprécie pas les gros framework comme Qt ou WxWidgets (contrairement à ce que j'ai pu laisser entendre pour des fins de trollage :p).
Vu que j'ai pas le choix, je m'en sers, mais c'est principalement parce que je ne connais pas de bibliothèque de toolkit n'accomplissant que leur tâche.
Oui, dans l'absolu, je préfèrerai un outil qui me permette de gérer les thread, un autre qui gère la traduction, un différent pour l'IHM, un distinct pour l'encodage, etc…
Même qu'ils soient regroupés sous un même nom, tant que je peux les utiliser complètement indépendamment les uns des autres, comme pour boost (quoique, certaines lib boost dépendent d'autres lib boost).
A mon sens, Qt est un langage qui ne s'assume pas: modification de la chaîne de compilation, ré-implémentation et volonté de remplacement de la STL, etc.
Il me semble idéal pour remplacer Java quand on veux plus de perf, en échange d'une syntaxe un peu plus complexe, par exemple.
Langage basé sur le C++, et qui se compile en générant du C++ ok, mais c'est bien ainsi que C++ à commencé: ça ne faisait que générer du C à partir de code C++, grâce à l'outil cfront. Ensuite, j'imagine qu'il fallait encore compiler…
Il y a juste un point qui m'intrigue dans le document que tu cites (le 2nd):
The only way is to rewrite it to work that way, or
to have more than one scheduler in the kernel. I don't want to do the former,
and mainline doesn't want to do the latter.
La dernière fois que j'ai fouillé dans les options de compilation du noyau il me semblait pourtant avoir vu plusieurs schedulers ?
C'est pas comme si je remets en cause les dires du monsieur, vu ma compréhension (ou mon manque de compréhension plutôt) de la chose, je m'abstiens volontiers, mais j'aimerai comprendre tout de même…
mais pour ça il y a ia32-libs (nom du paquet chez ubuntu).
Sous Debian stable aussi, mais ça va passer en multiarch très prochainement (prochaine release), ce qui signifie qu'au lieu de n'avoir que ia32-libs, tu vas devoir installer toutes les dépendances en version i386, et tant pis si tu les as déjà en amd64 manifestement. (y'a eu pas mal de bruit sur la ml à ce sujet)
Vu qu'Ubuntu est basée sur Debian, j'imagine qu'ils vont suivre le mouvement… bien que je sois surpris que ce ne soit pas déjà le cas, vu qu'en théorie ils sont basés sur debian sid qui utilise ce principe depuis pas loin d'un an…
Un des point très intéressant de l’architecture x86-64 qu'AMD a inventée en 2003 est de pouvoir faire tourner des programmes 32 bits sur un systèmes 64 bits. Mais tu le savais je pense.
En fait, il me semble que ça dépende d'une option du kernel (IA332), mais je ne suis pas un expert.
64bit kernels can execute 32bit programs since the IA32 instructions support is included in the kernel
En fonction de la distribution utilisée, cette option peut être présente ou pas, mais il y a aussi le problème des dépendances utilisées. Je pense que tu sais qu'il existe plusieurs façons de gérer ça. Dans le cas de Debian, la stable actuelle utilise une lib dédiée qui sert à faire la jonction entre les 2 mondes, tandis que l'actuelle testing nécessite l'installation des libs en version 32 bits.
Ce n'est donc pas si évident que tu ne sembles l'indiquer: si on utilise majoritairement des logiciels 32 bits (genre skype ou via wine) il peut être intéressant d'utiliser une distro 32 bit, même si personnellement je préfère les 64 bit.
Il y a eu une discussion sur la ml debian internationale au sujet du 32 bit, il faudrait que je la retrouve. (Il me semble qu'un certain Ralf avait fait une réponse très instructive sur les intérêts du 64 bit)
Le problème est que les évolutions coûtent parfois une quantité déraisonnable de ressources, et certains, dont je fais partie, considèrent que ça ne devrait pas être le cas.
Mais effectivement, j'ai fini par sélectionner plus rigoureusement mes logiciels pour ne pas avoir de fonctionnalité qui ne me sert à rien et ainsi alléger l'ensemble.
Desole, mais une interface en ncurse, ce n'est ni moderne ni joli.
Je ne dis pas que c'est moderne et/ou joli. Je dis juste que c'est aussi moderne (et bien plus moche, faut avouer) que 90% des applications récentes que j'aie vu.
Au final, les IHM sont toujours à base de boîtes de dialogues, de zones de saisie, de boutons à cocher etc… la grande différence c'est bien souvent tout ce qui a trait au thème de l'application: couleurs, fontes, écritures en gras taille 18, bla bla bla.
Ah, j'oubliai, il y a le support des périphériques de pointage qui est apparu (bah oui tu cites xerox quand même) mais ncurses aussi la supporte.
En fait, il y a les icônes qui manquent, je viens d'y penser. Mais ça doit être lié à ma manie de les enlever quasi-systématiquement sur mes logiciels du quotidien :D
Vu qu'on est entrain de troller, je suis plus tenter par la premiere explication ;-)
Le pire, c'est que même avec toute la mauvaise foi du monde je pourrai pas moinsser ça… vu que ça reviens a dire que le fait que j'aime pas qtcreator est une question de goût, donc d'une certaine façon de priorités.
Ha non! Privateur s'oppose à libérateur, pas à libre.
on est dans le domaine du droit, à mon sens.
Je suis bien d'accord. Mais alors, pourquoi utiliser un mot pour un concept qui à déjà le mot privatif comme j'ai cité plus haut, qui a un sens manifestement précis en droit?
J'ignorais que les contributeurs Debian maintenaient trois noyaux différents !
Hum, j'ai trop vite cru une source unique. Il semblerait que seuls les noyaux de KFreeBSD et Linux soient officiellement supportés. Mais si on ajoute la pléthore d'architecture, ça compte? XD
Il faudrait comparer avec la consommation mémoire d'une Debian en runlevel 1.
Heu… faut juste que je trouve comment booter directement en runlevel 1 et je te dis ça :)
Enfin, sinon, en switchant dans le runlevel 1, ça me donne
Je ne sais pas trop interpréter ces résultats, mais si ton 72Mo viens de la 2nde ligne, alors je suis à 46Mo. Sacrée différence quand même. Pas si on compare à 1Go de ram, bien sûr, mais un ratio important.
Concernant le manque de ressources sur les systèmes embarqués : aujourd'hui, même des appareils grand public comme des smartphones sont équipés de plusieurs centaines de Mo de mémoire vive, et de plusieurs Go de mémoire de stockage (un exemple).
Un autre exemple: le Raspberry_Pi. Toujours 512Mo de Ram (donc quelques centaines), mais si tu veux utiliser un navigateur internet, tu es mieux à ce que ton système d'init n'en bouffe pas 50 inutilement, quand on vois le poids des pages internet actuelles…
Mais dans l'absolu, je t'accordes qu'aujourd'hui on a de la place en RAM et HD.
Je trouve juste détestable le genre de propos (que j'ai entendus de mes profs de dev…) qui consiste à dire qu'on se fiche de l'occupation mémoire des logiciels qu'on écrit parce que le client bah "il a qu'a acheter de la ram".
Bah, disons que quand je m'en sers, tu peux enlever toutes les barres d'outil, fenêtres et barres de statut, je ne garde que l'affichage des fichiers source et la barre de menu.
Ensuite, au moment ou j'ai besoin des messages (par exemple) je les invoque avec un appui sur F2.
QtCreator est juste mille fois mieux foutu, ergonomiquement parlant et mille fois plus puissant.
Ca dépends des goûts.
Ca passe des menus contextuels à la paramétrabilité du soft, à l'intégration à gcc, à valgrind, à tous les systèmes de gestion de version connus, tout est pensé aux petits oignons.
Le seul truc que je ne retrouve pas dans ta liste, c'est la gestion des (D)VCS.
Pour valgrind, j'ai pas testé le plug-in de C::B, je suis "un peu" paumé avec cet outil. L'utiliser est sur ma todo list, mais… d'abord apprendre à gérer gdb correctement, on verra ensuite.
Niveau paramétrabilité, c'est simple, dans C::B aucun élément d'UI n'est fixe (ah, si, barre de menu et de statut, pardon), et leur (dé/re)placement est simplissime. Chose que je considère vitale et que je n'ai pas retrouvée dans QtCreator.
Après, honnêtement, depuis que j'ai découvert les tiling window manager et CMake, j'ai progressivement arrêté de l'utiliser, au profit de vim en éditeur de texte et de la compilation à coup de commandes. Reste le débugging ou j'ai pas encore trouvé l'outil qui corresponde complètement à mes besoins, mais cgdb me plaît pas mal. Ddd est un autre candidat à fort potentiel, ou peut-être voir pour intégrer gdb dans vim.
Ah, et, bien sûr, je n'utilise pas la version stable de C::B mais les nightly. Je préfère préciser.
Si, mais c'est pas une raison pour en rajouter. (D'ailleurs, si quelqu'un à une idée de comment faire ces fichues capitales accentuées sous windows, je suis preneur. Autre que "clic droit->corriger" bien entendu.)
Vrai que c'est mieux. Si quelqu'un peut trouver un screenchot où la barre de gauche avec les grosses icônes est enlevée, ainsi que la barre de statut en haut du source, la barre en bas, je pourrais me laisser un peu plus convaincre qu'on y perds pas tant de place.
Disons que je lui préfère de très loin Code::Blocks.
Après, les IHM c'est une pure question de goût: j'aime pas celle de QtCreator, mais ça me fera jamais dire que ses utilisateurs sont cinglés. Pas sans provocation de leur part en tout cas :)
Une interface graphique, c'est un truc qui sert à utiliser un programme sans galérer à taper des lignes de commandes super lourdes pour moi.
Si c'est pour voir du picasso, mieux vaux aller dans un musée, ça marchera mieux. Remplace les "quelques characteres colorise" par des zolies nimages colorisées et tu l'as, ton interface moderne…
Comme tant de gens, tu confond moderne et joli.
J'aurais du faire une quote, parce que bon, la, ton argumentaire, c'etait: "parce que c'est plus utilise, c'est donc un meilleur choix". Maintenant tu en changes la comprehension…
Le meilleur choix n'est pas toujours le meilleur choix technique (sinon windows serait beaucoup moins utilisé…). Et avoir plus d'utilisation peut permettre d'avoir aussi plus de retours. Je viens de regarder rapidement (10min). Jolie interface d'ailleurs, mais je trouve ça fouilli. Question de goûts, ça.) sur le site des EFL, je n'ai pas trouvé les infos que je chercherais, ou pas aussi vite, si je devais demain écrire une appli from scratch pour mon boulot et que je devais convaincre mon chef (quelqu'un à bien réussi à convaincre un chef de google que ça peut être une bonne idée pour google drive):
existence d'un support (y compris commercial) : wx affiche un onglet "support" et pas juste "contact", c'est plus intuitif je trouve.
facilité de téléchargement (un peu largué moi quand j'arrive sur la page "downloads" des EFL… c'est qu'il y en a du monde :) )
pas de screenshot (on parle de toolkit graphiques quand même non?) ah si je l'ai trouvé, en petit. Faut cliquer 3 fois dessus pour arriver à une image de taille correcte par contre.
quel langage est supporté? WxWidgets montre rapidement que c'est le C++, avec des binding perl, ruby, python… Dans le cas des EFL on sais pas trop… en tout cas j'ai pas trouvé (j'imagine que c'est une API C?)
une roadmap
Pour être réellement honnête, je suis tombé sur des incohérence de conception dans l'API de wxwidgets qui m'ont assez pourri la vie (la gestion du menu principal est chiante. Ca va si c'est pour faire un truc en dur, mais quand tu veux générer automatiquement des menus à partir d'un arbre de données… bref) mais de façon générale c'est pas trop lourd à l'exécution (pas un foudre de guerre non plus, clairement) et y'a moyen d'arriver vite fait à ses besoins.
L'avantage selon moi comparé à Qt, c'est l'absence d'outil intermédiaire dans la chaîne de compilation (outil qui m'a empêché de contribuer à un projet utilisant Qt parce que je n'ai jamais réussi à l'intégrer dans mes IDE, qui ne sont pas QtCreator qui n'est pas du tout à mon goût.).
Si tu me dis que les EFL sont portables et légères, tu me parles dans un langage qui me plaît, c'est le genre de trucs que j'aime réellement. D'ailleurs, je veux bien te croire, mais tu dis toi même que la page des systèmes supportés est obsolète… difficile de juger donc. Et je n'ai vu aucune preuve sur le site qu'une application EFL puisse tourner sous windows. Pour moi, c'est important, car 90% au bas mot des utilisateurs des appli que je fais risquent d'être sous cet OS.
C'est marrant, mais je n'ai jamais utilise la moindre application fait avec wxWidgets.
De mon côté j'en vois au moins 4 que j'aie utilisé (je parle pas de celles que j'ai jamais testé, mais j'en connais):
code::blocks (IDE C++)
filezilla (uniquement quand je suis sous windows, je trouve cet outil foireux comparé à gftp)
amaya (éditeur de page HTML, fait par le W3C)
flamerobin (un outil pour gérer une DB firebird)
C::B est assez connu chez les dev C++, et FileZilla est le 9ème projet le plus téléchargé de sourceforge (selon wikipedia, il a été 7ème à un moment).
Si tu me dis que tu n'en connais aucun des deux… c'est possible, mais surprenant. Peut-être que je les connais parce que je viens du monde windows, cela dit.
Par contre côté EFL je n'en vois vraiment aucune. A part E17… et il me semble que ça mis quelques années avant qu'il finisse par sortir, non?
Apres qu'on ne garantisse pas l'equivalence de fonctionalite, en tant que logiciel libre, c'est un peu normal. C'est le boulot d'une societe de faire la partie QA. En temps que logiciel libre, on fait que ca marche bien pour notre usage et on resoud autant que possible les bugs rapporte par nos utilisateurs.
Ca, c'est vrai pour le LL développé comme hobby par des barbus pour leur plaisir (moi quand je code pour mon plaisir, c'est des trucs en console d'ailleurs, alors vais pas cracher dans la soupe).
Si on prend des projets majeurs style LO, Firefox, projets autour (et dans) desquels je parie qu'on peut trouver des entreprises, trouver du support semble assez faisable, et ils font le maximum pour que leur produit fonctionne bien sur toutes les plate-formes qu'ils disent supporter officiellement.
Si j'utilise Firefox, je suis a peu près sûr qu'il marchera aussi bien sous Linux que sous Windows et que j'aurai les même fonctionnalités. Idem pour LO.
Chose que l'on retrouve dans wxWidgets: ce qui bloque le passage à la 3.0 sont des problèmes de compatibilité avec Mac OS. Preuve qu'ils testent et supportent réellement les différentes plates-formes, sinon ils auraient juste balancé la nouvelle release et basta.
Perso, je pense que les projets libres peuvent faire de la Q&A, et surtout que s'ils veulent des utilisateurs, ils le doivent.
Pour moi, commercialement parlant, utiliser les EFL en dehors du cadre très strict d'un matériel vraiment peu puissant est une mauvaise idée.
WxWidgets de ce côté semble quand même plus robuste.
Yep, je me demandais si quelqu'un allait réagir au sujet de l'IHM de wesnoth qui est… hum… primitive et lente :) (essayer d'utiliser le "nouveau" lobby mène à une mort par ennui certaine à force d'attendre que la machine accepte de se mettre à jour)
Par contre…
SDL et SDL_net ne sont pas des framework, mais des bibliothèques, qui n'imposent pas leur mainloop: c'est à l'utilisateur de l'implémenter.
Accessoirement, le but de ces outils est juste de donner un accès au matériel sans se prendre la tête, pas de faire des IHM, et je veux bien que tu m'indiques quel composant de wesnoth utilise le réseau pour permettre la communication entre 2 threads, je suis curieux. Si c'était le cas, ce serait moins lourd d'attendre après l'IA je pense.
Tu as répondu pour wesnoth. Tu pourrais répondre la même chose pour flare (mais tu ne connais peut-être pas ce jeu) sauf que les problèmes de perf ne sont pas aussi critiques (le jeu est moins lourd, et pas fini, ça doit aider).
Par contre, tu as laissé aptitude de côté? Et je vais ajouter ncmpcpp aussi, tiens.
Ncurses est utilisée par pas mal de programmes (plus que les EFL ou FLTK je pense :) ) et ne me semble pas implémenter les outils qui te semblent vitaux? Pourtant les IHM d'aptitude et de ncmpcpp ne sont vraiment pas crades, si on accepte de ne pas avoir de dégradés et autres fioritures graphiques.
Les intérêts du 64 bit ne se limitent pas à l'extension du l'utilisation de RAM… surtout que les OS 32 bit aussi peuvent le faire.
Il y a aussi les instructions supplémentaires, plus de registres généraux (donc, moins d'accès à la ram, donc plus de vitesse), les performances accrues pour les flottants il me semble, et d'autres choses du même genre.
Et oui, les adresses complètes prennent 2 fois plus de place, mais bon… un programme ne se compose pas que d'adresses mémoire.
Je suis curieux de savoir quelle distro tu as utilisée pour que la différence soit sensible en fait. Sur mon netbook l'occupation mémoire au boot est à 143Mo, dont la moitié dans le cache à vue de nez. (bon, faut pas rêver, la plupart des PC auront une consommation plus haute, rien qu'a cause de l'usage d'un DE)
Pour en revenir au thread initial, je vois surtout 1 raison d'utiliser du 32 bits: l'utilisation de wine ou d'applications qui ne sont pas compilées en 64 bit, genre skype. Flash n'entre pas dans cette catégorie.
Le ssd est pas dans mes moyens actuels (si je pouvais j'en mettrai un dans le netbook et 2 dans la tour ) mais pour la ram j'ai trouvé une solution très simple et très efficace: i3 + lxterminal.
Vim comme éditeur de texte, clang comme compilo, et j'ai plus jamais saturé la ram en compilant avec mes 4 threads. Le jour et la nuit, pour un environnement de dev.
Juste de temps en temps un coup de ramage parce que, décidément, ce disque dur est vraiment mesquinement lent… (du coup utiliser noatime et empecher vim de faire un fichier de backup en cas de problème a un peu aidé, mais c'est quand même pas la panacée)
[^] # Re: Le libre n'est pas viral
Posté par freem . En réponse à la dépêche L'accord cadre « Open Bar » Microsoft/Défense en cours de renégociation. Évalué à 1.
Pour le jeu ou il faut deviner un nombre aléatoirement choisis, tu utilises autre chose que la lib standard toi?
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -5.
Pour faire court: j'apprécie quand les outils que j'utilise ne sont pas liés les uns aux autres.
Je considère que si jamais je détecte un bug dans un tel outil, je peux le corriger.
Ça m'est d'ailleurs déjà arrivé, parce qu'un outil n'intégrant pas 10 000 fonctionnalités différentes, autrement suivant les principes du KISS, est bien plus simple à fixer.
Voila pourquoi je n'apprécie pas les gros framework comme Qt ou WxWidgets (contrairement à ce que j'ai pu laisser entendre pour des fins de trollage :p).
Vu que j'ai pas le choix, je m'en sers, mais c'est principalement parce que je ne connais pas de bibliothèque de toolkit n'accomplissant que leur tâche.
Oui, dans l'absolu, je préfèrerai un outil qui me permette de gérer les thread, un autre qui gère la traduction, un différent pour l'IHM, un distinct pour l'encodage, etc…
Même qu'ils soient regroupés sous un même nom, tant que je peux les utiliser complètement indépendamment les uns des autres, comme pour boost (quoique, certaines lib boost dépendent d'autres lib boost).
A mon sens, Qt est un langage qui ne s'assume pas: modification de la chaîne de compilation, ré-implémentation et volonté de remplacement de la STL, etc.
Il me semble idéal pour remplacer Java quand on veux plus de perf, en échange d'une syntaxe un peu plus complexe, par exemple.
Langage basé sur le C++, et qui se compile en générant du C++ ok, mais c'est bien ainsi que C++ à commencé: ça ne faisait que générer du C à partir de code C++, grâce à l'outil cfront. Ensuite, j'imagine qu'il fallait encore compiler…
[^] # Re: Vu de l'intérieur
Posté par freem . En réponse à la dépêche L'accord cadre « Open Bar » Microsoft/Défense en cours de renégociation. Évalué à 3.
Et celui du compilo qui compilera leur compilo.
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par freem . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 1.
D'ac, j'ai donc du confondre avec ceux des entrées/sorties. Merci de l'info.
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par freem . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 1.
Il y a juste un point qui m'intrigue dans le document que tu cites (le 2nd):
La dernière fois que j'ai fouillé dans les options de compilation du noyau il me semblait pourtant avoir vu plusieurs schedulers ?
C'est pas comme si je remets en cause les dires du monsieur, vu ma compréhension (ou mon manque de compréhension plutôt) de la chose, je m'abstiens volontiers, mais j'aimerai comprendre tout de même…
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par freem . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 6.
Oh, allez…. c'est pas comme si on pouvait pas parler de systemd sans déclencher un troll quand même si?
[^] # Re: œuf dur
Posté par freem . En réponse au message Installer une distrib 32b ou 64b sur portable 64b ?. Évalué à 3. Dernière modification le 29 avril 2013 à 14:03.
Sous Debian stable aussi, mais ça va passer en multiarch très prochainement (prochaine release), ce qui signifie qu'au lieu de n'avoir que ia32-libs, tu vas devoir installer toutes les dépendances en version i386, et tant pis si tu les as déjà en amd64 manifestement. (y'a eu pas mal de bruit sur la ml à ce sujet)
Vu qu'Ubuntu est basée sur Debian, j'imagine qu'ils vont suivre le mouvement… bien que je sois surpris que ce ne soit pas déjà le cas, vu qu'en théorie ils sont basés sur debian sid qui utilise ce principe depuis pas loin d'un an…
[^] # Re: RAM
Posté par freem . En réponse au message Installer une distrib 32b ou 64b sur portable 64b ?. Évalué à 1.
En fait, il me semble que ça dépende d'une option du kernel (IA332), mais je ne suis pas un expert.
http://www.sysresccd.org/Kernel
En fonction de la distribution utilisée, cette option peut être présente ou pas, mais il y a aussi le problème des dépendances utilisées. Je pense que tu sais qu'il existe plusieurs façons de gérer ça. Dans le cas de Debian, la stable actuelle utilise une lib dédiée qui sert à faire la jonction entre les 2 mondes, tandis que l'actuelle testing nécessite l'installation des libs en version 32 bits.
Ce n'est donc pas si évident que tu ne sembles l'indiquer: si on utilise majoritairement des logiciels 32 bits (genre skype ou via wine) il peut être intéressant d'utiliser une distro 32 bit, même si personnellement je préfère les 64 bit.
Il y a eu une discussion sur la ml debian internationale au sujet du 32 bit, il faudrait que je la retrouve. (Il me semble qu'un certain Ralf avait fait une réponse très instructive sur les intérêts du 64 bit)
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Evidemment que le thread est mieux dans ce cas. Maintenant, décompresser un fichier n'a pas grand chose à voir avec l'IHM que je sache…
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Le problème est que les évolutions coûtent parfois une quantité déraisonnable de ressources, et certains, dont je fais partie, considèrent que ça ne devrait pas être le cas.
Mais effectivement, j'ai fini par sélectionner plus rigoureusement mes logiciels pour ne pas avoir de fonctionnalité qui ne me sert à rien et ainsi alléger l'ensemble.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 3.
Je ne dis pas que c'est moderne et/ou joli. Je dis juste que c'est aussi moderne (et bien plus moche, faut avouer) que 90% des applications récentes que j'aie vu.
Au final, les IHM sont toujours à base de boîtes de dialogues, de zones de saisie, de boutons à cocher etc… la grande différence c'est bien souvent tout ce qui a trait au thème de l'application: couleurs, fontes, écritures en gras taille 18, bla bla bla.
Ah, j'oubliai, il y a le support des périphériques de pointage qui est apparu (bah oui tu cites xerox quand même) mais ncurses aussi la supporte.
En fait, il y a les icônes qui manquent, je viens d'y penser. Mais ça doit être lié à ma manie de les enlever quasi-systématiquement sur mes logiciels du quotidien :D
:-)
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 3.
Toi, tu sais que tu viens de changer ma vie?
[^] # Re: :/
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -1.
Le pire, c'est que même avec toute la mauvaise foi du monde je pourrai pas moinsser ça… vu que ça reviens a dire que le fait que j'aime pas qtcreator est une question de goût, donc d'une certaine façon de priorités.
[^] # Re: Propriétaire non, privateur oui
Posté par freem . En réponse au journal Privateur.... Évalué à 4.
Ha non! Privateur s'oppose à libérateur, pas à libre.
Je suis bien d'accord. Mais alors, pourquoi utiliser un mot pour un concept qui à déjà le mot privatif comme j'ai cité plus haut, qui a un sens manifestement précis en droit?
[^] # Re: Re: Quelles distributions utilisent systemd par défaut ?
Posté par freem . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2. Dernière modification le 29 avril 2013 à 11:28.
Hum, j'ai trop vite cru une source unique. Il semblerait que seuls les noyaux de KFreeBSD et Linux soient officiellement supportés. Mais si on ajoute la pléthore d'architecture, ça compte? XD
Heu… faut juste que je trouve comment booter directement en runlevel 1 et je te dis ça :)
Enfin, sinon, en switchant dans le runlevel 1, ça me donne
Je ne sais pas trop interpréter ces résultats, mais si ton 72Mo viens de la 2nde ligne, alors je suis à 46Mo. Sacrée différence quand même. Pas si on compare à 1Go de ram, bien sûr, mais un ratio important.
Un autre exemple: le Raspberry_Pi. Toujours 512Mo de Ram (donc quelques centaines), mais si tu veux utiliser un navigateur internet, tu es mieux à ce que ton système d'init n'en bouffe pas 50 inutilement, quand on vois le poids des pages internet actuelles…
Mais dans l'absolu, je t'accordes qu'aujourd'hui on a de la place en RAM et HD.
Je trouve juste détestable le genre de propos (que j'ai entendus de mes profs de dev…) qui consiste à dire qu'on se fiche de l'occupation mémoire des logiciels qu'on écrit parce que le client bah "il a qu'a acheter de la ram".
[^] # Re: :/
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -4.
Bah, disons que quand je m'en sers, tu peux enlever toutes les barres d'outil, fenêtres et barres de statut, je ne garde que l'affichage des fichiers source et la barre de menu.
Ensuite, au moment ou j'ai besoin des messages (par exemple) je les invoque avec un appui sur F2.
Ca dépends des goûts.
Le seul truc que je ne retrouve pas dans ta liste, c'est la gestion des (D)VCS.
Pour valgrind, j'ai pas testé le plug-in de C::B, je suis "un peu" paumé avec cet outil. L'utiliser est sur ma todo list, mais… d'abord apprendre à gérer gdb correctement, on verra ensuite.
Niveau paramétrabilité, c'est simple, dans C::B aucun élément d'UI n'est fixe (ah, si, barre de menu et de statut, pardon), et leur (dé/re)placement est simplissime. Chose que je considère vitale et que je n'ai pas retrouvée dans QtCreator.
Après, honnêtement, depuis que j'ai découvert les tiling window manager et CMake, j'ai progressivement arrêté de l'utiliser, au profit de vim en éditeur de texte et de la compilation à coup de commandes. Reste le débugging ou j'ai pas encore trouvé l'outil qui corresponde complètement à mes besoins, mais cgdb me plaît pas mal. Ddd est un autre candidat à fort potentiel, ou peut-être voir pour intégrer gdb dans vim.
Ah, et, bien sûr, je n'utilise pas la version stable de C::B mais les nightly. Je préfère préciser.
[^] # Re: AMHA
Posté par freem . En réponse au journal Privateur.... Évalué à 0.
Si, mais c'est pas une raison pour en rajouter. (D'ailleurs, si quelqu'un à une idée de comment faire ces fichues capitales accentuées sous windows, je suis preneur. Autre que "clic droit->corriger" bien entendu.)
[^] # Re: :/
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -5.
Vrai que c'est mieux. Si quelqu'un peut trouver un screenchot où la barre de gauche avec les grosses icônes est enlevée, ainsi que la barre de statut en haut du source, la barre en bas, je pourrais me laisser un peu plus convaincre qu'on y perds pas tant de place.
Disons que je lui préfère de très loin Code::Blocks.
Après, les IHM c'est une pure question de goût: j'aime pas celle de QtCreator, mais ça me fera jamais dire que ses utilisateurs sont cinglés. Pas sans provocation de leur part en tout cas :)
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 0.
Une interface graphique, c'est un truc qui sert à utiliser un programme sans galérer à taper des lignes de commandes super lourdes pour moi.
Si c'est pour voir du picasso, mieux vaux aller dans un musée, ça marchera mieux. Remplace les "quelques characteres colorise" par des zolies nimages colorisées et tu l'as, ton interface moderne…
Comme tant de gens, tu confond moderne et joli.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 2.
Le meilleur choix n'est pas toujours le meilleur choix technique (sinon windows serait beaucoup moins utilisé…). Et avoir plus d'utilisation peut permettre d'avoir aussi plus de retours. Je viens de regarder rapidement (10min). Jolie interface d'ailleurs, mais je trouve ça fouilli. Question de goûts, ça.) sur le site des EFL, je n'ai pas trouvé les infos que je chercherais, ou pas aussi vite, si je devais demain écrire une appli from scratch pour mon boulot et que je devais convaincre mon chef (quelqu'un à bien réussi à convaincre un chef de google que ça peut être une bonne idée pour google drive):
pas de screenshot (on parle de toolkit graphiques quand même non?)ah si je l'ai trouvé, en petit. Faut cliquer 3 fois dessus pour arriver à une image de taille correcte par contre.Pour être réellement honnête, je suis tombé sur des incohérence de conception dans l'API de wxwidgets qui m'ont assez pourri la vie (la gestion du menu principal est chiante. Ca va si c'est pour faire un truc en dur, mais quand tu veux générer automatiquement des menus à partir d'un arbre de données… bref) mais de façon générale c'est pas trop lourd à l'exécution (pas un foudre de guerre non plus, clairement) et y'a moyen d'arriver vite fait à ses besoins.
L'avantage selon moi comparé à Qt, c'est l'absence d'outil intermédiaire dans la chaîne de compilation (outil qui m'a empêché de contribuer à un projet utilisant Qt parce que je n'ai jamais réussi à l'intégrer dans mes IDE, qui ne sont pas QtCreator qui n'est pas du tout à mon goût.).
Si tu me dis que les EFL sont portables et légères, tu me parles dans un langage qui me plaît, c'est le genre de trucs que j'aime réellement. D'ailleurs, je veux bien te croire, mais tu dis toi même que la page des systèmes supportés est obsolète… difficile de juger donc. Et je n'ai vu aucune preuve sur le site qu'une application EFL puisse tourner sous windows. Pour moi, c'est important, car 90% au bas mot des utilisateurs des appli que je fais risquent d'être sous cet OS.
De mon côté j'en vois au moins 4 que j'aie utilisé (je parle pas de celles que j'ai jamais testé, mais j'en connais):
C::B est assez connu chez les dev C++, et FileZilla est le 9ème projet le plus téléchargé de sourceforge (selon wikipedia, il a été 7ème à un moment).
Si tu me dis que tu n'en connais aucun des deux… c'est possible, mais surprenant. Peut-être que je les connais parce que je viens du monde windows, cela dit.
Par contre côté EFL je n'en vois vraiment aucune. A part E17… et il me semble que ça mis quelques années avant qu'il finisse par sortir, non?
Ca, c'est vrai pour le LL développé comme hobby par des barbus pour leur plaisir (moi quand je code pour mon plaisir, c'est des trucs en console d'ailleurs, alors vais pas cracher dans la soupe).
Si on prend des projets majeurs style LO, Firefox, projets autour (et dans) desquels je parie qu'on peut trouver des entreprises, trouver du support semble assez faisable, et ils font le maximum pour que leur produit fonctionne bien sur toutes les plate-formes qu'ils disent supporter officiellement.
Si j'utilise Firefox, je suis a peu près sûr qu'il marchera aussi bien sous Linux que sous Windows et que j'aurai les même fonctionnalités. Idem pour LO.
Chose que l'on retrouve dans wxWidgets: ce qui bloque le passage à la 3.0 sont des problèmes de compatibilité avec Mac OS. Preuve qu'ils testent et supportent réellement les différentes plates-formes, sinon ils auraient juste balancé la nouvelle release et basta.
Perso, je pense que les projets libres peuvent faire de la Q&A, et surtout que s'ils veulent des utilisateurs, ils le doivent.
Pour moi, commercialement parlant, utiliser les EFL en dehors du cadre très strict d'un matériel vraiment peu puissant est une mauvaise idée.
WxWidgets de ce côté semble quand même plus robuste.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Il consomme beaucoup plus de ram que clang. Tu devrais tester, c'est assez bluffant la différence.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 2.
Yep, je me demandais si quelqu'un allait réagir au sujet de l'IHM de wesnoth qui est… hum… primitive et lente :) (essayer d'utiliser le "nouveau" lobby mène à une mort par ennui certaine à force d'attendre que la machine accepte de se mettre à jour)
Par contre…
SDL et SDL_net ne sont pas des framework, mais des bibliothèques, qui n'imposent pas leur mainloop: c'est à l'utilisateur de l'implémenter.
Accessoirement, le but de ces outils est juste de donner un accès au matériel sans se prendre la tête, pas de faire des IHM, et je veux bien que tu m'indiques quel composant de wesnoth utilise le réseau pour permettre la communication entre 2 threads, je suis curieux. Si c'était le cas, ce serait moins lourd d'attendre après l'IA je pense.
Tu as répondu pour wesnoth. Tu pourrais répondre la même chose pour flare (mais tu ne connais peut-être pas ce jeu) sauf que les problèmes de perf ne sont pas aussi critiques (le jeu est moins lourd, et pas fini, ça doit aider).
Par contre, tu as laissé aptitude de côté? Et je vais ajouter ncmpcpp aussi, tiens.
Ncurses est utilisée par pas mal de programmes (plus que les EFL ou FLTK je pense :) ) et ne me semble pas implémenter les outils qui te semblent vitaux? Pourtant les IHM d'aptitude et de ncmpcpp ne sont vraiment pas crades, si on accepte de ne pas avoir de dégradés et autres fioritures graphiques.
[^] # Re: :/
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
J'ai pris la 1ère venue.
Non, tu auras 5 affichages de code source. Si tu affiches 5 codes sources en même temps dans QtCreator, je n'ose imaginer le résultat…
[^] # Re: RAM
Posté par freem . En réponse au message Installer une distrib 32b ou 64b sur portable 64b ?. Évalué à 4.
Les intérêts du 64 bit ne se limitent pas à l'extension du l'utilisation de RAM… surtout que les OS 32 bit aussi peuvent le faire.
Il y a aussi les instructions supplémentaires, plus de registres généraux (donc, moins d'accès à la ram, donc plus de vitesse), les performances accrues pour les flottants il me semble, et d'autres choses du même genre.
Et oui, les adresses complètes prennent 2 fois plus de place, mais bon… un programme ne se compose pas que d'adresses mémoire.
Je suis curieux de savoir quelle distro tu as utilisée pour que la différence soit sensible en fait. Sur mon netbook l'occupation mémoire au boot est à 143Mo, dont la moitié dans le cache à vue de nez. (bon, faut pas rêver, la plupart des PC auront une consommation plus haute, rien qu'a cause de l'usage d'un DE)
Pour en revenir au thread initial, je vois surtout 1 raison d'utiliser du 32 bits: l'utilisation de wine ou d'applications qui ne sont pas compilées en 64 bit, genre skype. Flash n'entre pas dans cette catégorie.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 0.
Le ssd est pas dans mes moyens actuels (si je pouvais j'en mettrai un dans le netbook et 2 dans la tour ) mais pour la ram j'ai trouvé une solution très simple et très efficace: i3 + lxterminal.
Vim comme éditeur de texte, clang comme compilo, et j'ai plus jamais saturé la ram en compilant avec mes 4 threads. Le jour et la nuit, pour un environnement de dev.
Juste de temps en temps un coup de ramage parce que, décidément, ce disque dur est vraiment mesquinement lent… (du coup utiliser noatime et empecher vim de faire un fichier de backup en cas de problème a un peu aidé, mais c'est quand même pas la panacée)