Articles précédents : Développeur
- [23] AJAX Chat Engine a besoin de vous
- [24] Première version stable de la forge CodingTeam
- [40] Akrogen, greffon Eclipse de génération de code, avec wizard pages décrits en XML/XUL
- [4] Trophées du libre 2007 : vous pouvez postuler dès maintenant !
- [15] Développer des composants graphiques en PHP
- [13] Un aperçu de Netbeans 6.0
- [13] Blocs notes BasKet à la recherche de développeurs
- [88] OCaml 3.10.0 est sorti
- [15] Journées Python Francophones
- [69] Sortie de GCC 4.2
Liens connexes
- Anjuta (1214 hits)
- Annonce de la 2.2.0 (233 hits)
- Présentation des fonctionnalités (428 hits)
- Captures d'écrans (1709 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Anjuta 2.2.0 - Hurricane - est sorti
Posté par Étienne Bersac (Jabber id, page perso, ). Modéré le 27 juin 2007.
Anjuta a de sérieux atouts pour le développement d'applications GNOME : bonne intégration avec les autotools, SVN, gdb, valgrind, devhelp et glade. Utilisation de technologies GNOME (Gtk+, VTE, GtkSourceView, etc.). Gestion de nombreux langages (C, C++, Java, Python). Tout cela dans un logiciel très léger au final (comparé à Eclipse par exemple).
![[en]](../../../images/en.png)
Anjuta (1214 hits)-
Annonce de la 2.2.0 (233 hits)
-
Présentation des fonctionnalités (428 hits)
-
Captures d'écrans (1709 hits)
> Lire la suite (50 commentaires, moyenne: 2,2). [dépêche : 2231 caractères]
- Anjuta propose une interface très modulaire avec des docks façon Gimp.
- Avec les dernières versions de Glade, Anjuta propose un concepteur d'interface intégré et élégant ;
- Gestionnaire de fichier modulaire (permet l'ajout de la gestion de SVN/CVS/… par exemple) ;
- Gestionnaire de projet basé sur les Autotools. Vous pouvez perfectionner vos Makefile.am sans gêner Anjuta. Les Autotools sont très reconnus pour leur portabilité et l'étendue de leur solution (de la compilation à la distribution). Anjuta peut en outre ouvrir n'importe quel projet basé sur les autotools ;
- L'assistant de création de projet. Pas besoin d'être un gourou des autotools !
- L'assistant de création de fichier, avec notamment la création de GObject ;
- Édition avec Scintilla ou GtkSourceView ;
- Déboggeur très bien intégré (gdb et valgrind sont disponibles) et un profiler ;
- Intégration de devhelp pour naviguer très simplement dans la documentation ;
- Gestionnaire de tâches (TODO).
Malgré cela, Anjuta a encore des domaines où il peut s'améliorer :
- Une gestion plus dynamique du code. Par exemple : ajouter un bloc de documentation à une fonction, renommer une fonction globalement (sans passer par rechercher/remplacer), etc.
- Une meilleure gestion de l'indentation (à quand l'équivalent d'emacs ?) ;
- Meilleure gestion des tags du projet ;
- Intégration de distutils pour python. (M'enfin, faudrait déjà que distuils gère la désinstallation …) ;
- …
[+] kdevelop
Quand je pense que Kdevelop sait deja faire tout ca et meme mieux depuis si longtemps
-
[^]Re: kdevelop
Posté par Axel R. (page perso, ) le 27/06/2007 à 14:53. (lien). Évalué à 2.Et quand je pense qu'avec le temps qu'on passe à apprendre à utiliser emacs, on n'a plus le temps d'utiliser toutes ces fonctionnalités...
Bah, tu vois, moi aussi j'arrive à troller un autre jour que le vendredi !
Axel
[+] eclipse
t'as rien compris a Eclipse si tu dis qu'Eclipse est lourd. Tu peux tout modulariser et garder toute sa puissance quand meme
-
[^]Re: eclipse
Posté par Sufflope (Jabber id, page perso, ) le 27/06/2007 à 18:02. (lien). Évalué à 1.Pour la lourdeur d'Eclipse : depuis que j'ai modifié /etc/eclipse/java_home (en tout cas c'est là sous Ubuntu) pour qu'il se lance avec Java 1.6 de Sun au lieu de GCJ, il a pris un sacré coup de boost !
Attention ça n'a rien à voir avec la JVM choisie dans les préférences qui concerne le lancement des programmes développés avec.
[+] un bon editeur...
Y'a que ca de vrai. Pourquoi s'emmerder avec des environnements aussi lourds que ca alors qu'un bon VIM fait tout deja tout seul.
-
[^]Re: un bon editeur...
Posté par Olivier Abad () le 27/06/2007 à 08:09. (lien). Évalué à 5.VIM est déjà inutilement lourd. Rien ne vaut un bon cat + Ctrl D
-
[^]Re: un bon editeur...
Posté par PoFMaN (Jabber id, ) le 27/06/2007 à 08:17. (lien). Évalué à 3.Moi aussi j'aime bien vim, mais ce qui me manque c'est l'intégration d'un débuggeur parce que gdb tout seul j'ai du mal (je loupe peut être quelque chose en fait).
Sinon il a l'air simpa cet IDE faudrai que je l'essaye (y a besoin d'installer des lib gnome pour en profiter?)-
[^]Re: un bon editeur...
Posté par liberforce (Jabber id, page perso, ) le 27/06/2007 à 08:29. (lien). Évalué à 5.Effectivement, ce qui manque réellement, c'est un bon débuggeur, ou plutôt un bon frontend pour GDB. C'est pour ça que le projet Nemiver a été lancé, et qu'on espère qu'il sera intégré à GNOME un jour.
http://home.gna.org/nemiver/
Anjuta a malheureusement mis tellement de temps à se stabiliser ou même à devenir exploitable qu'il a bien fallu trouver d'autres solutions. Moi je venais du monde Windows + Visual C++, ça m'a fait bizarre quand j'ai cherché l'équivalent sous Linux... Depuis je suis passé à vim+autotools, mais je ne suis plus très sûr qu'un outil unique soit LA solution, tout simplement parce que ça devient un monstre trop lourd à maintenir et à s'adapter aux nouveautés dans ce domaine...
M'enfin ce nouvel anjuta mérite un coup d'oeil (j'y avais touché l'année dernière et il plantait régulièrement sur l'assistant de création de projet, ce qui m'avait pas mal découragé). J'espère que la stabilité s'est améliorée.-
[^]Re: un bon editeur...
Posté par Étienne Bersac (Jabber id, page perso, ) le 27/06/2007 à 11:36. (lien). Évalué à 5.Salut,
Tu as dû toucher Anjuta 2.0 qui est la première alpha de la lignée 2.X. Anjuta a une numérotation assez déroutante. Pour avoir utilisé Anjuta SVN depuis quelques mois (gnome-scan 0.5 a été totalement écrit avec anjuta SVN), je regrette d'emacs son indentation parfaite et sa profusion de raccourcis (Anjuta a des raccourcis éditable façon Gtk+, ça aide).
Anjuta est loin d'être un tout en un. Au contraire, il est l'agrégation de beaucoup d'outils existant. Je me demande d'ailleurs ce qu'il va advenir de nemiver et moap. Vont-il être intégré dans Anjuta ? Un simple plugin suffit. Il y a déjà deux alternative pour éditer (SourceView et Scintilla). Rien n'empêche Anjuta de tirer parti des projet existants. C'est là que j'apprécie beaucoup Anjuta par rapport à Eclipse ou certains IDE python.
Cordialement,
Étienne.--
E Ultreïa !-
[^]Re: un bon editeur...
Posté par gpe () le 27/06/2007 à 11:55. (lien). Évalué à 0.Moi ce qui me gêne dans les IDE c'est que chacun réinvente son propre éditeur de texte alors qu'il y en a déjà pléthore et que bien souvent ils sont moins bon que ceux déjà existant.
Pour le reste ils s'appuient sur des éléments déjà existant mais pas pour cet élément majeur qu'est l'éditeur, pourquoi?
Bref je ne suis pas prêt d'échanger mon baril de vim contre 2 barils d'Anjuta ou Eclipse ou autre.-
[^]Re: un bon editeur...
Posté par imalip (page perso, ) le 27/06/2007 à 12:25. (lien). Évalué à 6.chacun réinvente son propre éditeur de texte alors qu'il y en a déjà pléthore
Comme dit dans le post auquel tu réponds, Anjuta utilise pour l'édition de texte au choix Scintilla (back-end de SciTE, un projet qui a 8 ans, et était deja utilisé dans Anjuta 1.X) ou GtkSourceView, une extension a GTK+ qui fait partie du projet GNOME et est déja utilisé par gedit et MonoDevelop. Pas certain qu'ils aient réinventé quoi que ce soit, contrairement a ce que tu dis.--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
-
[^]Re: un bon editeur...
Posté par Troy McClure (page perso, ) le 27/06/2007 à 12:42. (lien). Évalué à 4.Moi ce qui me gêne dans les IDE c'est qu'ils sont tous très attachés à un environnement: anjuta = gnome sous linux, kdevelop = kde sous linux, msvc = windows, xcode = macos, ... Donc finalement quand on veut faire du dev sur les trois plateformes, il faut se farcir trois usines à gaz differentes, trois gestionnaires de projets differents, avec leurs lourdeurs et leurs bugs particuliers.
Au final, les seuls environnements vraiments cross-plateformes, c'est xemacs et vim :) (j'ai mis vim pour faire plaisir aux vimistes, mais il est evident que la seule solution sérieuse est xemacs).-
[+] [^]Re: un bon editeur...
Posté par vrm (page perso, ) le 27/06/2007 à 12:57. (lien). Évalué à -1.ben non Eclipse+CDT ça marche pour les trois.
-
[^]Re: un bon editeur...
Posté par Troy McClure (page perso, ) le 27/06/2007 à 13:05. (lien). Évalué à 5.Et c'est vraiment valable CDT par rapport à éditer directement ses fichiers c++ avec notepad.exe ? parce que la dernière fois que j'ai posé la question, on m'a certifié que c'etait de la bouse en branches (je dis ça sans parti pris, c'est juste un ouï-dire)
-
[^]Re: un bon editeur...
Posté par Olivier Abad () le 27/06/2007 à 15:07. (lien). Évalué à 4.La dernière fois que j'ai essayé (en Janvier), CDT ne savait pas indenter, ce qui est déjà rédhibitoire, et la complétion était inutilisable : 1 minute d'attente minimum à chaque fois (il parait que les performances sont meilleurs sous Windows mais je n'en ai pas vraiment l'utilité).
-
-
-
[^]Re: un bon editeur...
Posté par CrEv (page perso, ) le 27/06/2007 à 13:50. (lien). Évalué à 5.c'est surtout que le problème est mal pris je pense.
Je développe actuellement pour windows et linux en même temps.
Mon projet est décrit uniquement dans un fichier CMakeLists.txt [http://www.cmake.org]
Si je veux une version makefile classique :
cmake
Si je veux une version kdevelop :
cmake -G KDevelop3
Si je veux une version vs6, vs7, vs8, codeblocks, mingw, ... il suffit de demander à l'utilitaire cmake sous windows.
En clair, jamais on ne s'occupe des problèmes de gestion des différents projets selon les ide (ou non) car cmake le fait pour nous.
Les seuls problèmes sont donc liés aux compilateurs différents (compiler win/linux avec mingw/gcc ça passe encore, mais pour faire du vc++/gcc, c'est déjà plus galère, mais c'est une autre histoire ;))
Donc finalement, pour faire du multiplateforme, il suffit de choisir les bons outils et dans ce cas l'environnement de codage n'influe plus (ou alors de manière assez négligeable)
(sinon, xemacs sux, seul emacs rox !)
-
-
-
-
-
[^]Re: un bon editeur...
Posté par David () le 27/06/2007 à 09:35. (lien). Évalué à 2.essaie ddd, c'est une tres bonne interface graphique autour de gdb.
-
[^]Re: un bon editeur...
Posté par liberforce (Jabber id, page perso, ) le 27/06/2007 à 09:51. (lien). Évalué à 4.Franchement, ddd c'est antédiluvien, et franchement je ne le trouve pas très pratique non plus. Mais c'est toujours mieux que gdb en ligne de commande...
-
[^]Re: un bon editeur...
Posté par Émilien Tlapale (page perso, ) le 28/06/2007 à 08:04. (lien). Évalué à 1.J'avoue que je ne debugge pas très souvent de gros projets mais je ne vois pas le problème de gdb (à mon niveau). Il affiche bien les registres, les valeurs à n'importe quelle adresse. En plus il comprend le code et me donne les correspondance avec les fichiers sources et est même capable de de comprendre des expressions c direct dans son interface. Interface qui me permet de descendre et remonter dans la pile, de mettre des breakpoints, des watch sur des variables (ou autres), de faire du step by step...
En gros, c'est quoi l'avantage de ddd (ou autre) ??-
[^]Re: un bon editeur...
Posté par liberforce (Jabber id, page perso, ) le 28/06/2007 à 08:19. (lien). Évalué à 3.C'est simple: tu ne passes pas 3 plombes à te demander "C'est quoi déjà la commande qui fait ça ? C'est quoi les paramètres ? C'est dans quelle section de l'aide ?". L'outil en lui même n'a aucun problème en terme de fonctionnalité. La preuve en est bien que tous les autres débuggers sont des fontends à gdb. Les problèmes que l'on évoque, c'est ceux de l'interface entre l'utilisateur et outil, les problèmes d'ergonomie.
-
[^]Re: un bon editeur...
Posté par Étienne Bersac (Jabber id, page perso, ) le 28/06/2007 à 12:43. (lien). Évalué à 2.J'ajoute aussi l'intégration. Quand emacs ou Anjuta me pointe directement dans la ligne incriminé par le segfault, c'est utile et ça fait plaisir :)
--
E Ultreïa !
-
-
[^]Re: un bon editeur...
Posté par Thomas Douillard () le 28/06/2007 à 08:27. (lien). Évalué à 4.Si il y avait un seul truc : la facilité pour poser un breakpoint n'importe où ... en un simple clic, sans avoir à se poser plus de questions que ça.
-
-
-
-
-
[^]Re: un bon editeur...
Posté par karmatronic () le 27/06/2007 à 08:26. (lien). Évalué à 0.si tu dois juste faire des scripts , en effet avec vim , c est suffisant.
même si t as besoin d une interface graphique en GTK ou QT, glade ou designer se suffisent á eux meme.
par contre , si tu fais un gros projet en C/C++, tu ne peux pas te contenter d un gdb en ligne de commandes, il te faut un gros debugger intégré et visuel .
de ce côté la , faut un peu tatonner au debut mais quand on a trouvé,comme dab, on se rend compte que c etait debile.
gros point noir pour anjuta , y a pas beaucoup de docs dispos sur le net , on a l impression qu il n y a que 4 pelerins (dont ma femme) qui utilisent cet outil .
perso, je peux pas supporter kdevellop et anjuta est l unique alternative
de toute façon (si on veut un vrai IDE) ,sous reserve de tester codeblocks ou geany
je me demande ce qu utilisent les devellopeurs du noyau -ils sont pas tous sur kde quand même:)-
[^]Re: un bon editeur...
Posté par Jux (page perso, ) le 27/06/2007 à 08:44. (lien). Évalué à 1.par contre , si tu fais un gros projet en C/C++, tu ne peux pas te contenter d un gdb en ligne de commandes, il te faut un gros debugger intégré et visuel .
de ce côté la , faut un peu tatonner au debut mais quand on a trouvé,comme dab, on se rend compte que c etait debile.
(je ne suis pas sûr d'avoir compris le "débile" de la dernière phrase)
C'est un peu un mythe ça... La majorité (sinon tous) des débuggeurs visuels sous Linux sont justes des interfaces pour gdb. Après je crois que c'est essentiellement une question de préférence personnelle, certains aime la ligne de commande, d'autres n'aiment pas.
C'est un peu le même genre d'argument que dire "ouais la ligne de commande et autoconf c'est bien, mais dès que tu fais un gros projet C/C++, faut un IDE à la visual où tu peux gérer visuellement ta compilation".-
[^]pas d accord
Posté par karmatronic () le 27/06/2007 à 09:10. (lien). Évalué à 2.moi , je pense plutot que la plupart des gens qui crient au scandale dès qu on critique gdb sont des mecs qui n ont jamais eu á debugger des gros projets....
je le sais, c est aussi ce que je pensais mais un IDE avec debugger integré, c est pas du luxe c est un vrai besoin souvent.
après , on est bien d accord que sous anjuta , le debugger est une surcouche de gdb.
enfin , il s agit pas de critiquer la "ligne de commandes" (ce qui relève du blasphème), mais une ligne de commandes , ce n est pas l unique solution même si c est souvent la meilleure ( enfin , je sais pas , peut être que tu regardes tes films en ascii dans un terminal ,mais tout content de transporter le son avec esd.....)-
[^]Re: pas d accord
Posté par Mathieu SCHROETER (page perso, ) le 27/06/2007 à 10:59. (lien). Évalué à 1.Le problème n'est pas la ligne de commande, mais uniquement de connaître les commandes. SI tu maîtrises toutes les commandes de GDB, un gros projet ne te fera aucun souci. Même au contraire, tu gagneras du temps car tu as accès à plus de possibilités qu'une GUI comme ddd ou kdbg (par exemple).
-
[^]Re: pas d accord
Posté par liberforce (Jabber id, page perso, ) le 28/06/2007 à 07:19. (lien). Évalué à 4.Pour avoir essayé d'apprendre à utiliser gdb et gnuplot, je peux te certifier que le temps d'apprentissage n'en vaut pas la chandelle: si tu t'en sers tous les 36 du mois tu ne retiens pas 1/4 des commandes, alors qu'en comparaison, débugger un programme sous Visual C++ 5 était ultra facile.
La ligne de commande c'est bien, mais quand chacun se met à réinventer son propre langage, ça devient lourd. C'est là qu'une IHM peut te faire gagner beaucoup de temps.-
[^]Re: pas d accord
Posté par Mathieu SCHROETER (page perso, ) le 01/07/2007 à 20:58. (lien). Évalué à 2.C'est relatif, faut bien nuancer entre le programmeur occasionnel et régulier.
Je compare personnellement GDB et une GUI comme Visual C++ XYZ (d'ailleurs GDB est aussi une IHM) plutôt à la fonction `find` couplée avec des expressions régulières et le petit chien de Windows XP pour faire une recherche dans les fichiers.
Les regex ont à envie de les vomir les premières fois, mais ça en vaut largement la chandelle d'y "perdre" ses heures..
Ou un autre exemple.. comparer OpenOffice (Office) avec LaTeX. Franchement, apprendre à faire du TeX c'est chiant, mais le gain de temps (à terme) est hallucinant :-).
Enfin ça n'engage que moi.. mais je comprend ton point de vue.
-
-
-
[^]Re: pas d accord
Posté par Jux (page perso, ) le 27/06/2007 à 11:05. (lien). Évalué à 6.moi , je pense plutot que la plupart des gens qui crient au scandale dès qu on critique gdb sont des mecs qui n ont jamais eu á debugger des gros projets....
C'est quoi un "gros projet", 10'000 lignes ? 100'000 ? 1'000'000 ?
Perso, j'ai bossé sur poppler et evince qui comptent respectivement 100'000 et 60'000 lignes de codes d'après sloccount
enfin , il s agit pas de critiquer la "ligne de commandes" (ce qui relève du blasphème), mais une ligne de commandes , ce n est pas l unique solution même si c est souvent la meilleure ( enfin , je sais pas , peut être que tu regardes tes films en ascii dans un terminal ,mais tout content de transporter le son avec esd.....)
Ou ai-je dis que la ligne de commande était l'unique solution ? Ai-je dis que les interfaces pour débugger c'est _mal_ ?
Non ! J'ai simplement dis que pas mal de gens qui bossent sur des gros projets s'en sortent très bien avec vim/emacs et gdb et que les trucs graphiques ne sont _pas_ (contrairement à ce que tu affirme) une nécessité pour tout le monde, même sur des gros projets avec des programmeurs experimentés.
Pour appuyer mes dire, je te renvoie à ce journal (ou on remarque que certains programmeurs pas tout à fait débutant n'aiment carrément pas les debuggers) et notamment à l'avis d'un certain Linus.
Alors maintenant, il est clair que certains très bons programmeurs préfèrent avoir une interface graphique, ça n'enlève rien à leur compétence, c'est juste que c'est une question de choix personnel.
C'était mon coup de gueule du jour, mais j'en ai un peu marre du discours qui considère que c'est plus "pro" d'utiliser un IDE et que vim/gdb c'est pour les hackers du dimanche et les étudiants. C'est juste une question de choix...-
[^]Les liens...
Posté par Jux (page perso, ) le 27/06/2007 à 11:06. (lien). Évalué à 1.Arf mince les liens ne sont pas passés :
Le journal en question : http://linuxfr.org/~Krunch/22577.html
L'avis de Linus : http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.h(...)
-
[^]Re: pas d accord
Posté par karmatronic () le 27/06/2007 à 14:05. (lien). Évalué à 2.je crois qu on ne se comprend pas trop la
perso , je suis fan de vim, je pense qu il faut être un expert pour tirer toute la quintessence de gdb ,tandis que ma femme par exemple s en sort sans aucun problème avec le debugguer intégré d anjuta.
on a pas tous á être fans d unix/linux pour pouvoir faire du C
si tu interprètes ça comme une diatribe contre les outils issus du shell,libre á toi .-
[^]Re: pas d accord
Posté par Jux (page perso, ) le 27/06/2007 à 14:28. (lien). Évalué à 4.Ben moi je dis juste l'affirmation suivante est eronnée, c'est tout :-)
par contre , si tu fais un gros projet en C/C++, tu ne peux pas te contenter d un gdb en ligne de commandes, il te faut un gros debugger intégré et visuel .
-
[^]Re: pas d accord
Posté par liberforce (Jabber id, page perso, ) le 28/06/2007 à 07:23. (lien). Évalué à 4.Si tu t'en sers tous les jours, gdb convient tout à fait. Mais perso je ne sors mon débugger que quand j'ai un problème hors norme que je n'arrive pas à repérer avec du "printf debugging". Résultat: impossible de me rappeler les bonnes commandes gdb vu que je ne l'utilise pas assez souvent. Une IHM te donne beaucoup plus d'information plus rapidement quand tu es un utilisateur occasionnel, et demande moins d'apprentissage.
C'est à l'outil de s'adapter à l'utilisateur et pas l'inverse.-
[^]Re: pas d accord
-
[^]Re: pas d accord
Posté par ham () le 30/06/2007 à 05:59. (lien). Évalué à 0.je debug a coup de trace et je ne me sert de gdb aussi que pour des problemes hors norme et je trouve plus simple de me souvenir de la commande backtrace, print et x, alors les Interfaces graphiques ou il faut aller chercher a quoi correspond quel bouton, regarder la structure des menus, ben je ne trouve pas que cela requiert moins d'apprentisage qu'une aide bien structuré.
si certains ont une mémoire plus visuel, ils ont le droit de préférer un outils graphique.
Si ont a le choix on peut prendre l'outilsque l'on veut.
Sinon quand on a pas le choix , si l'utlisateur n'arrive pas a s'adapter a l'outils, changer d'utilisateur.-
[^]Re: pas daccord
Posté par Joël SCHAAL () le 03/07/2007 à 12:08. (lien). Évalué à 1.les Interfaces graphiques ou il faut aller chercher à quoi correspond quel bouton, regarder la structure des menus,...
Mauvaise GUI -> changer de GUI !
Sérieusement, une GUI (Graphical User Interface) bien faite vaut tous les mans* du monde.
J'explique ce que j'entends par "bien faite" avant de me faire moinsser en masse :
- le type de controle est dépendant du type de donnée : on ne met pas des cases à cocher au lieu de bouton radio pour des choix mutuellement exclusifs, une zone de texte multiligne pour entrer un code postal, ou une liste multisélection quand on doit choisir le sexe de la personne...
- chaque contrôle doit avoir une nomenclature autoexplicative (self-explanatory) :
mauvais exemple : [ ] use GDS
.meilleur exemple : [x] search also with GoogleDesktopSearch
- chaque contrôle doit avoir un Tooltip qui décrit plus en détails la fonction remplie par ce contrôle, ainsi que les choix possibles.
- dans le meilleur des cas, il devrait être possible d'accéder à la catégorie dans l'aide correspondant au contrôle courant pour obtenir les dernières infos qui manquent dans un cas spécifique (par exemple : hésitation entre 2 options avancées difficilement explicable en quelques lignes)
- les contrôles doivent être catégorisés, soit par arbre (à la VLC), soit par onglet (les exemples ne manquent pas) soit par un mélange des deux.
- dans le meilleur des cas, on devrait pouvoir entrer un texte qui agira comme filtre pour n'afficher que les catégories contenant une ou des options contenant le texte en question.
- les contrôles doivent être relativement espacé pour apporter un confort visuel, mais pas trop pour ne pas avoir une fenêtre immense, ou des onglets à foison.
- les contrôles doivent pouvoir être filtrés par niveau d'utilisation (novice, habitué, expert, ...). Tout le monde ne trouve pas cette manière très efficace, une variante pourrait consister a mettre les infos générale en premier, les plus utilisées après et les autres ensuite.
- le texte des contrôles devrait être défini dans des ressources pour que la GUI soient facilement traduisibles dans une autre langue.
Alors, bien sûr, c'est de la grande théorie et tous les points n'ont pas besoin d'être respectés pour obtenir un résultat attrayant et efficace. Mais en en respectant la plupart,
1) on configure son outil tout aussi facilement qu'avec un fichier de configuration
2) on fait en général moins de fautes (restriction de choix, aide à la saisie,...)
3) on découvre plus faiclement des options qui peuvent nous être utiles mais qu'on ne cherchait pas de prime abord
4) on accède a l'aide de manière ciblée et on a pas besoin de potasser tout le manuel pour savoir comment gérer UNE option.
(*) : dois-je préciser que je me limite aux applications graphiques, et donc aux mans qui leur sont spécifiques ?
-
-
-
-
-
-
-
-
Indentation
Bah si l'indentation n'a toujours pas été corrigé c'est vraiment dommage. Parce que bon avoir un éditeur qui forme à utiliser une conventation (ou quelques conventions) en particulier c'est particulièrement nuisible à une collaboration basé sur des standards. En particulier quand j'avais essayé il était impossible de suivre les conventions GNU (automatiquement je veux dire), rien que pour ça Emacs est quand même vachement mieux (en plus de pouvoir envoyer des emails avec).
-
[^]Re: Indentation
Posté par Étienne Bersac (Jabber id, page perso, ) le 27/06/2007 à 11:44. (lien). Évalué à 2.Salut,
Anjuta utilise indent, mais bizarrement, ça foire. Même dans Scintilla/SourceView, c'est foireux. En fait, le comptage des caractère par tabulation est foireux. Résultat, si tu aligne verticalement des paramètre de fonction, ça foire (pour les prototypes). Il y a aussi la gestion des switch qui est passablement foireuse.
Voilà pour les détails.
Étienne--
E Ultreïa !-
[^]Re: Indentation
Posté par Frédéric-Emmanuel Picca () le 27/06/2007 à 12:23. (lien). Évalué à 1.Est-ce que l'on peut utiliser astyle à la place de indent ?
astyle gère mieux le C++ qu'indent qui est purement C.
-
[^]Re: Indentation
Posté par Flavien Bridault (page perso, ) le 29/06/2007 à 22:18. (lien). Évalué à 1.Ouais ben si ça c'est pas amélioré de ce côté là c'est même pas la peine que je l'essaye... Je suis complètement accro à l'indentation d'emacs, je ne comprends vraiment pas qu'aucun éditeur ou IDE (à part xemacs) ne parvient à ou ne veut pas reproduire ce type d'indendation...
-
[^]Re: Indentation
Posté par Moonz () le 30/06/2007 à 07:03. (lien). Évalué à 3.Pour les ignares qui ont abandonné emacs quand on leur a dit "lisp", qu'a t-il de si merveilleux ce système d'indentation ? (moi, j'ai surtout ouïe dire qu'Emacs se démerde très mal avec les tabulations)
-
[^]Re: Indentation
Posté par Émilien Tlapale (page perso, ) le 12/07/2007 à 12:52. (lien). Évalué à 2.Bah il ne dépend pas d'un utilitaire externe (même s'il pourrait) genre indent mais est scriptable (en lisp :) donc extrèmement puissant et configurable. Pour l'utilisateur lambda qui ne souhaite pas se faire chier à reconfigurer le mécanisme d'indentation, emacs est fournit avec quelques modes d'indentation très sympa dont le GNU (pour les gens qui respectent les GNU Coding Standards), K&R, Linux, ...
Quand à l'histoire des tabulations je n'en ai jamais entendu parler. Ça peut venir du fait que Emacs peut utiliser un mélange de charactères tabulations et espaces pour faire l'indentation (perso je n'utilise jamais de tabulation dans mes codes sources, donc avec la config emacs qui va avec).
-
-
-
Dépendances !
Si seulement il était beaucoup moins dépendant de Gnome. Je n'ai pas envie non plus d'installer tout gnome pour installer cet IDE!
-
[^]Re: Dépendances !
Posté par Guillaume Caron (Jabber id, ) le 27/06/2007 à 10:07. (lien). Évalué à 10.Bah en même temps, il est conçu avec des technos GNOME pour créer des applis GNOME, fallait pas s'attendre a être dépendant de Qt !
--
« How ’bout a magic trick? Taa-daa! It’s…ah, it’s gone. »
Gestion de version
Perso, une des fonctions que j'attend d'un IDE, c'est de m'aider dans la gestion de version. Je vois, avec plaisir, que SVN est maintenant intégré à anjuta, je vais donc le tester à la moindre occasion.
Par contre, depuis quelques mois, j'ai quitté le monde CVS/Subversion pour me tourner vers un monde nouveau (pour moi) : celui des gestion de version décentralisée (Git, Mercurial et consort).
Savez-vous si des gens travaillent à intégrer ces outils dans Anjuta ?
-
[^]Re: Gestion de version
Posté par Étienne Bersac (Jabber id, page perso, ) le 28/06/2007 à 12:47. (lien). Évalué à 3.SVN est plutôt bien intégré, même si je n'aime pas trop l'affichage de la diff et que je ne peux pas sélectionner certains fichiers pour le commit (c'est soit le fichier courant, soit tout le projet … peut pas envoyer un .h et un .c ensemble :-| ).
Git/Mercurial/Tla/Bzr et consorts ne sont pas supporté, mais ce n'est qu'un question de greffons. D'ailleurs, je n'ai aucune trace de CVS dans Anjuta, vu que je ne charge pas le greffon associé. Y'a du bon dans la modularité :-)
Cordialement,
Étienne.--
E Ultreïa !-
[^]Re: Gestion de version
Posté par Bonnefille Guilhem (page perso, ) le 29/06/2007 à 07:18. (lien). Évalué à 1.SVN est plutôt bien intégré, même si je n'aime pas trop l'affichage de la diff et que je ne peux pas sélectionner certains fichiers pour le commit (c'est soit le fichier courant, soit tout le projet … peut pas envoyer un .h et un .c ensemble :-| ).
Ben si on peut pas commiter un .c et son .h sans emporter le reste du projet, alors je dirais que SVN est plutôt mal intégré. En effet, c'est un des apports majeurs de SVN par rapport à CVS la notion de changeset.
-
Cette page a été générée par Templeet en 0.1886s (dont 0.0198 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.