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)
Peut-être que ça leur permettra de mieux séparer les différentes couches du code, du coup, et que la prochaine fois que ça leur prend ça sera moins compliqué.
Imagines, ils pourraient faire une version en ncurses, avec transformation du flux vidéo grâce à caca.
Bon, c'est vrai que du traitement de vidéo en ncurses, ça pue un peu…
Peut-être que toutes les applications n'ont pas besoin de décompresser des images et textures lourdes, tout simplement.
Si je prends le cas de Code::Blocks, de Visual Studio, de galculator… je ne crois pas que ces outils aient le moindre besoin de décompresser des images lourdes.
Le multi-thread est utile dans mes exemples, mais surtout pour les 2 IDE, et n'est pas vraiment lié à l'IHM, plutôt de l'auto-complétion de code.
Accessoirement, vue la puissance de calcul des machines modernes, on pourrait objecter qu'on ne le sentirai pas.
Attention, je ne remets pas en cause l'utilité des threads: je me moque de mon karma mais quand même, faut pas pousser. Juste qu'ils ne sont pas nécessaires dans la plupart des applications qui n'ont pas de tâches lourdes à faire. Et créer un thread à un coût, en ressources mais aussi en débogage.
Oui, l'ordinateur est fait pour être utilisé, et non je ne cherche pas a faire tendre le load average vers 0.
Je cherche juste à ce que ma machine réagisse le plus vite possible à mes demandes, et à ce que les temps de compilation diminuent le plus possible.
Et la, force est de constater que quand j'utilisais un IDE ou même des environnements graphiques classiques sur mon netbook, ces besoins n'étaient pas satisfaits: la machine mettait du temps à réagir à mes injonctions et la compilation faisant saturer la ram, la machine swappait terriblement. Dans le genre ralentisseur de compilation, c'est pas mal. En plus quand ça swapait je pouvais rien faire d'autre pour au moins 5 minutes.
Et pourtant, je faisait attention à n'avoir que des outils utilisant GTK. Je ne doute pas une seconde que si j'avais utilisé XFCE avec, par exemple, KDevelop, j'aurai souffert encore plus.
Vraiment, je te conseilles de consulter cette page avant de continuer à parler de std::string :D
Tu y remarqueras que la découpe et la recherche se font très bien, le stockage de float se fait aussi sans souci.
Les 3 points qu'il te reste sont tous liés à l'encodage. Je ne sais pas si C++11 à intégré des fonctionnalités liées aux conversions d'encodage, mais ce qui est sûr, c'est qu'on peut au moins utiliser d'autres encodages depuis: http://en.wikipedia.org/wiki/C%2B%2B11#New_string_literals
Ton point de vue se défend, mais je ne suis pas convaincu.
Je vais prendre deux exemples simples: wesnoth et flare. Ce sont des jeux, mais ils ont quand même des contrôles graphiques permettant les actions habituelles: cases à cocher, bouton cliquable, zone de saisie, etc.
Je vais prendre chacun des points que tu as levé, et on va voir s'ils y sont intégrés.
Tu as besoin d'une gestion des event => oui
Tu as besoin d'asynchrone => non
Tu as besoin de thread. => non (wesnoth n'utilise pas de thread pour ses IHM. Pas dis que je trouve ça bien, juste que ça montre que ce n'est pas vital)
En gros, tu as besoin d'une main loop => non (elle y est, mais je doute très fort qu'elle soit gérée par les contrôles graphiques. Dans le cas de flare, c'est une quasi-certitude.)
Tu as besoin de discuter avec des process separe => non
alors tu rajoutes une petite couche reseau => non (je ne pense pas que le réseau aie quoique ce soit à voir avec l'IHM de wesnoth, et il est absent de flare)
divers demon dont ton framework a besoin => non
Je pourrais aussi citer aptitude, maintenant que j'y pense, qui a le mérite de ne pas être un jeu, mais je ne pense pas qu'il y ait conflit avec la plupart des points précédents.
En fait, je viens de me souvenir de FLTK. Jamais utilisé parce que le projet m'a l'air quelques peu chaotique, mais il semble bien que ça sois relativement proche d'un toolkit ne faisant que s'occuper des IHM.
Windows est plus utilise que Linux sur le desktop. Argumentaire de masse toujours imparable.
Désolé de considérer que les applications que je fais doivent pouvoir tourner sur la plus grande quantité possible de cibles.
Et les efls sont certainement plus portable que wxwidgets, a partir du moment ou tu as un framebuffer et un debut de libc, ca passe.
Je vais même t'aider un peu. D'ailleurs, en tant que personne qui les promeut, sache que tu me déçois énormément de ne pas avoir toi-même cité une partie de ce passage du site officiel:
Enlightenment and EFL support several platforms, though Linux is the primary platform of choice for our developers, some make efforts to make things work on FreeBSD and other BSD's, Solaris, MacOS X, Windows (XP, Vista, 7 etc.), Windows CE and more. Compatibility will vary , but most of core EFL support all Linuxes, BSD's, Solaris and other UNIX-like OS's. Mac support should work mostly thanks to the X11 support in OS X, and Windows support exists for most of the core libraries (XP, Vista, 7, CE).
Mais peut-être est-ce dû aux nombreuses portions de phrase qui donnent une impression de truc pas fini?
Si j'utilise des lib de préférence portable, c'est justement pour ne pas avoir besoin de galérer à vérifier quelle fonctionnalité l'est ou pas, personnellement.
Enfin bon… il y a une façon simple de savoir si les gens préfèrent les EFL à wxWidgets ou le contraire, et c'est de voir des applications célèbres les utilisant. Sans même prendre la peine de réfléchir, wxWidgets a FileFilla.
Je me demande toujours comment des gens efficaces peuvent faire pour utiliser un IDE qui perds autant d'espace…
Je sais pas pour emacs, et j'ai utilisé des IDE pour le moindre programme que j'ai fait jusqu'a l'an dernier, quand j'ai commencé à utiliser vim. Je suis loin de le maîtriser et je lui trouve énormément de défauts, mais je n'ai pas encore vu d'IDE me permettant de coder aussi efficacement, c'est à dire sans me forcer à utiliser la souris dès que je veux utiliser une commande, qui ne gâche pas la précieuse place de l'écran de mon ordinateur portable (j'ai 4H de train par jour, alors ça m'arrive souvent de programmer dans le train, et non, j'ai pas accès à des 17" dans le train)
Bref, je ne qualifierais pas les utilisateurs d'IDE de particulièrement sains d'esprit non plus. En tout cas, pas plus que ceux qui préfèrent des éditeurs de textes puissants.
Oui, je pense aussi que ça doit être dur de faire tourner Qt sur du matériel comme celui là…
Youpi. Ca marche sur 1/3 de mes machines… Ca marche bien entendu aussi sur le netbook, je le sais, et peut-être même sur l'ordinosaure. Par contre, sauf sur la machine de bureau, ça augmente sensiblement la charge.
Mais je présume qu'il est inutile de chercher à te convaincre que charger 2 bibliothèques qui servent à faire la même chose augmente la charge du système…
T'en vois beaucoup toi des applications qui activent de la transparence sur leurs widgets ?
Sur leurs widgets particulièrement non. De toute façon tu as raison, celles utilisant la transparence ça n'existebien entendu pas…
D'ailleurs tu ne peux pas imaginer le temps que ça m'a pris pour inventer les fausses preuves contenues dans les liens que j'ai mis… au moins 20s.
Donc au final, on a payé un logiciel qui finit par ne plus être utilisable au sens installation
Ok. Donc, quand tu achètes une voiture à essence, en fait tu la loues parce que dans 50 ans il n'y aura plus de pétrole et que donc tu ne pourras plus l'utiliser?
[^] # 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)
[^] # Re: Windows
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Peut-être que ça leur permettra de mieux séparer les différentes couches du code, du coup, et que la prochaine fois que ça leur prend ça sera moins compliqué.
Imagines, ils pourraient faire une version en ncurses, avec transformation du flux vidéo grâce à caca.
Bon, c'est vrai que du traitement de vidéo en ncurses, ça pue un peu…
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 0.
Peut-être que toutes les applications n'ont pas besoin de décompresser des images et textures lourdes, tout simplement.
Si je prends le cas de Code::Blocks, de Visual Studio, de galculator… je ne crois pas que ces outils aient le moindre besoin de décompresser des images lourdes.
Le multi-thread est utile dans mes exemples, mais surtout pour les 2 IDE, et n'est pas vraiment lié à l'IHM, plutôt de l'auto-complétion de code.
Accessoirement, vue la puissance de calcul des machines modernes, on pourrait objecter qu'on ne le sentirai pas.
Attention, je ne remets pas en cause l'utilité des threads: je me moque de mon karma mais quand même, faut pas pousser. Juste qu'ils ne sont pas nécessaires dans la plupart des applications qui n'ont pas de tâches lourdes à faire. Et créer un thread à un coût, en ressources mais aussi en débogage.
[^] # Re: :/
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 5.
Bah c'est sûr, avec des outils qui bouffent la moitié de l'écran, c'est plus confortable :D
[^] # 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.
Oui, l'ordinateur est fait pour être utilisé, et non je ne cherche pas a faire tendre le load average vers 0.
Je cherche juste à ce que ma machine réagisse le plus vite possible à mes demandes, et à ce que les temps de compilation diminuent le plus possible.
Et la, force est de constater que quand j'utilisais un IDE ou même des environnements graphiques classiques sur mon netbook, ces besoins n'étaient pas satisfaits: la machine mettait du temps à réagir à mes injonctions et la compilation faisant saturer la ram, la machine swappait terriblement. Dans le genre ralentisseur de compilation, c'est pas mal. En plus quand ça swapait je pouvais rien faire d'autre pour au moins 5 minutes.
Et pourtant, je faisait attention à n'avoir que des outils utilisant GTK. Je ne doute pas une seconde que si j'avais utilisé XFCE avec, par exemple, KDevelop, j'aurai souffert encore plus.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 0.
Vraiment, je te conseilles de consulter cette page avant de continuer à parler de std::string :D
Tu y remarqueras que la découpe et la recherche se font très bien, le stockage de float se fait aussi sans souci.
Les 3 points qu'il te reste sont tous liés à l'encodage. Je ne sais pas si C++11 à intégré des fonctionnalités liées aux conversions d'encodage, mais ce qui est sûr, c'est qu'on peut au moins utiliser d'autres encodages depuis: http://en.wikipedia.org/wiki/C%2B%2B11#New_string_literals
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Ton point de vue se défend, mais je ne suis pas convaincu.
Je vais prendre deux exemples simples: wesnoth et flare. Ce sont des jeux, mais ils ont quand même des contrôles graphiques permettant les actions habituelles: cases à cocher, bouton cliquable, zone de saisie, etc.
Je vais prendre chacun des points que tu as levé, et on va voir s'ils y sont intégrés.
Je pourrais aussi citer aptitude, maintenant que j'y pense, qui a le mérite de ne pas être un jeu, mais je ne pense pas qu'il y ait conflit avec la plupart des points précédents.
En fait, je viens de me souvenir de FLTK. Jamais utilisé parce que le projet m'a l'air quelques peu chaotique, mais il semble bien que ça sois relativement proche d'un toolkit ne faisant que s'occuper des IHM.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 5.
Désolé de considérer que les applications que je fais doivent pouvoir tourner sur la plus grande quantité possible de cibles.
Je vais même t'aider un peu. D'ailleurs, en tant que personne qui les promeut, sache que tu me déçois énormément de ne pas avoir toi-même cité une partie de ce passage du site officiel:
Mais peut-être est-ce dû aux nombreuses portions de phrase qui donnent une impression de truc pas fini?
Si j'utilise des lib de préférence portable, c'est justement pour ne pas avoir besoin de galérer à vérifier quelle fonctionnalité l'est ou pas, personnellement.
Enfin bon… il y a une façon simple de savoir si les gens préfèrent les EFL à wxWidgets ou le contraire, et c'est de voir des applications célèbres les utilisant. Sans même prendre la peine de réfléchir, wxWidgets a FileFilla.
[^] # Re: :/
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 3.
Je me demande toujours comment des gens efficaces peuvent faire pour utiliser un IDE qui perds autant d'espace…
Je sais pas pour emacs, et j'ai utilisé des IDE pour le moindre programme que j'ai fait jusqu'a l'an dernier, quand j'ai commencé à utiliser vim. Je suis loin de le maîtriser et je lui trouve énormément de défauts, mais je n'ai pas encore vu d'IDE me permettant de coder aussi efficacement, c'est à dire sans me forcer à utiliser la souris dès que je veux utiliser une commande, qui ne gâche pas la précieuse place de l'écran de mon ordinateur portable (j'ai 4H de train par jour, alors ça m'arrive souvent de programmer dans le train, et non, j'ai pas accès à des 17" dans le train)
Bref, je ne qualifierais pas les utilisateurs d'IDE de particulièrement sains d'esprit non plus. En tout cas, pas plus que ceux qui préfèrent des éditeurs de textes puissants.
[^] # 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é à -4.
Youpi. Ca marche sur 1/3 de mes machines… Ca marche bien entendu aussi sur le netbook, je le sais, et peut-être même sur l'ordinosaure. Par contre, sauf sur la machine de bureau, ça augmente sensiblement la charge.
Mais je présume qu'il est inutile de chercher à te convaincre que charger 2 bibliothèques qui servent à faire la même chose augmente la charge du système…
Sur leurs widgets particulièrement non. De toute façon tu as raison, celles utilisant la transparence ça n'existe bien entendu pas…
D'ailleurs tu ne peux pas imaginer le temps que ça m'a pris pour inventer les fausses preuves contenues dans les liens que j'ai mis… au moins 20s.
[^] # Re: Où ?
Posté par freem . En réponse au journal Privateur.... Évalué à 4.
Ok. Donc, quand tu achètes une voiture à essence, en fait tu la loues parce que dans 50 ans il n'y aura plus de pétrole et que donc tu ne pourras plus l'utiliser?