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). Outre la stabilité accrue et les nombreuses corrections de bogues, Anjuta 2.2.0 propose de sensibles améliorations en terme de fonctionnalités. En voici les principales :
- 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 …) ;
- …
Aller plus loin
- Anjuta (26 clics)
- Annonce de la 2.2.0 (6 clics)
- Présentation des fonctionnalités (16 clics)
- Captures d'écrans (9 clics)
# kdevelop
Posté par yim yom (site web personnel) . Évalué à -9.
[^] # Re: kdevelop
Posté par Axel R. (site web personnel) . Évalué à 2.
Bah, tu vois, moi aussi j'arrive à troller un autre jour que le vendredi !
Axel
# eclipse
Posté par yim yom (site web personnel) . Évalué à -10.
[^] # Re: eclipse
Posté par Sufflope (site web personnel) . Évalué à 1.
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.
[^] # Re: eclipse
Posté par Sufflope (site web personnel) . Évalué à -1.
# un bon editeur...
Posté par yim yom (site web personnel) . Évalué à -1.
[^] # Re: un bon editeur...
Posté par Olivier Abad . Évalué à 5.
[^] # Re: un bon editeur...
Posté par PoFMaN . Évalué à 3.
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 (site web personnel) . Évalué à 5.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: un bon editeur...
Posté par gpe . Évalué à 0.
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 . Évalué à 6.
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.
[^] # Re: un bon editeur...
Posté par gpe . Évalué à 2.
[^] # Re: un bon editeur...
Posté par Gniarf . Évalué à 8.
[^] # Re: un bon editeur...
Posté par Troy McClure (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à -1.
[^] # Re: un bon editeur...
Posté par Troy McClure (site web personnel) . Évalué à 5.
[^] # Re: un bon editeur...
Posté par Olivier Abad . Évalué à 4.
[^] # Re: un bon editeur...
Posté par CrEv (site web personnel) . Évalué à 5.
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 . Évalué à 2.
[^] # Re: un bon editeur...
Posté par liberforce (site web personnel) . Évalué à 4.
[^] # Re: un bon editeur...
Posté par Émilien Tlapale . Évalué à 1.
En gros, c'est quoi l'avantage de ddd (ou autre) ??
[^] # Re: un bon editeur...
Posté par liberforce (site web personnel) . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: un bon editeur...
Posté par Thomas Douillard . Évalué à 4.
[^] # Re: un bon editeur...
Posté par karmatronic . Évalué à 0.
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 (site web personnel) . Évalué à 1.
(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 . Évalué à 2.
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 (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: pas d accord
Posté par liberforce (site web personnel) . Évalué à 4.
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 (site web personnel, Mastodon) . Évalué à 2.
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 (site web personnel) . Évalué à 6.
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
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 (site web personnel) . Évalué à 1.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 4.
[^] # Re: pas d accord
Posté par liberforce (site web personnel) . Évalué à 4.
C'est à l'outil de s'adapter à l'utilisateur et pas l'inverse.
[^] # Re: pas d accord
Posté par Pol' uX (site web personnel) . Évalué à 4.
Mouais, mais le mauvais utilisateur à (selon lui) toujours de mauvais outils.
Adhérer à l'April, ça vous tente ?
[^] # Re: pas d accord
Posté par ham . Évalué à 0.
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 . Évalué à 1.
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
Posté par Émilien Tlapale . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Indentation
Posté par Frédéric-Emmanuel Picca . Évalué à 1.
astyle gère mieux le C++ qu'indent qui est purement C.
[^] # Re: Indentation
Posté par Flavien Bridault (site web personnel) . Évalué à 1.
[^] # Re: Indentation
Posté par Moonz . Évalué à 3.
[^] # Re: Indentation
Posté par Émilien Tlapale . Évalué à 2.
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 !
Posté par Stephen Amar . Évalué à 2.
[^] # Re: Dépendances !
Posté par zebra3 . Évalué à 10.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Gestion de version
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
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 ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Gestion de version
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.