Sortie de Anjuta 2.0.0

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
16
mai
2005
Gnome
Anjuta est un environnement de développement intégré (IDE) C/C++ pour GNOME, disposant de nombreuses fonctionnalités: gestion de projet, assistants, outils de debogage, support cvs, exploration de symboles...
Son éditeur de code source, reposant sur Scintilla, comprend coloration syntaxique, autocompletion, etc.

La version 2.0 est la première de la série 2.0.x, nouvelle branche dont l'architecture a été totalement revue pour séparer le code en librairies (libanjuta, GDL, Gnome-build) et offrir aux développeurs de plugins de nouvelles possibilités.

La dernière version stable de anjuta était la 1.2.2, sortie en avril 2004. Cette version est pour le moment considérée comme non stable, mais les développeurs insistent sur la nécessité de la tester et de reporter les bugs. Par ailleurs, elle peut fonctionner en parallèle de la version 1.x, à condition d'utiliser un préfixe différent pour l'installation.

Enfin, on peut noter la sortie simultanée de la version 1.2.3, qui contient uniquement des corrections de bogues pour la "vieille" branche 1.x. Changements notables pour la 2.0.0:

* Système de docking des élements ala gimp 2.x
* Système de plugins dynamique très complet, pouvant interagir avec l'interface et ainsi rajouter/changer les menus, barres d'outils, menus contextuels, etc.
* Intégration devhelp
* Intégration glade (incomplète pour le moment)
* Support de gnome-vfs, permettant par exemple l'édition d'un document à distance.
* Gestionnaire de tache revu et corrigé
* Support subversion (incomplet pour le moment) et amélioration du support cvs.
* Possibilité de générer un diagramme des classes d'un projet C++
* Amélioration du debogueur (lequel utilise GDB)

Aller plus loin

  • # Pas encore dispo pour Gentoo

    Posté par  . Évalué à -6.

    j'attends qu'elle apparaisse sur Portage et après on pourra tester..

    • [^] # Re: Pas encore dispo pour Gentoo

      Posté par  (site web personnel) . Évalué à 8.

      A vue de nez (pas regardé le forum ni le bugzilla) ca va poser un peu probleme: si on veut toutes les options, faut glade 3 depuis le cvs, des trucs genre GDL / Gnome-Build qui ne sont pas packagés... Clairement, cette release risque d'etre réservée aux bidouilleurs...

      Cela étant dit, c'est une avancée majeure, préfigurant de grandes choses pour anjuta. D'ou l'interet de la tester :)

  • # IDE

    Posté par  . Évalué à 2.

    Pour l'instant, je n'utilise pas d'IDE pour développer (ligne de commande et éditeur de texte ...).

    Je vais peut-etre me mettre à en tester, donc si vous en connaissez d'autres (Kdevelop, Eclipse ...) et vous les avez testez, vos commentaires sont bienvenues :)

    Personnellement, j'en aimerais bien un qui permette l'intégration de mon éditeur de texte favoris.

    • [^] # Re: IDE

      Posté par  (site web personnel) . Évalué à 5.

      Si l'éditeur de texte en question est vim, il en existe un KPart pour l'intégrer dans Kdevelop, qui est d'ailleurs un excellent IDE je trouve.

    • [^] # Re: IDE

      Posté par  . Évalué à 4.

      Je trouve qu'on en fait un peu trop au sujet d'Eclipse, c'est peut-être un bon soft pour faire du Java mais pour faire du C/C++, c'est une catastrophe. Il est super lent et on ne parle même pas de la complétion automatique qui met 3h avant d'arriver à l'écran. Il plante souvent et on a constamment l'impression de travailler avec un IDE en version beta. Pour du C/C++, c'est soit Anjuta et KDevelop, avec une préférence pour ce dernier mais je pense que la 2.0 va changer la donne.

      • [^] # Re: IDE

        Posté par  . Évalué à 1.

        "on" est prié de ne pas prendre son cas pour une généralité et d'utiliser "je" à bon escient.

    • [^] # Re: IDE

      Posté par  (site web personnel) . Évalué à 8.

      Pour développer du Java, tu as moult IDE, en ce qui me concerne je suis très satisfait d'Eclipse.

      Pour du C/C++, oublie Eclipse, le plugin CDT n'est pas encore au point, ca rame, ca autocomplète mal, ... Peut être cela viendra t-il un jour, mais par pour le moment en tout cas.
      Je te conseille d'utiliser SciTe (lui aussi utilise la base scintilla, très légère mais très aboutie !), ce n'est pas un IDE mais presque !

      Tu peux aussi essayer code::blocks, qui semble bien fonctionner (je ne l'ai cependant pas encore essayé sur de gros projets)
      http://www.codeblocks.org/index.php(...) . Il gère l'autocomplétion, le débugage et il est pluginable.

      Et pour windows, il y a aussi devcpp, http://www.bloodshed.net/devcpp.html.(...) Il fonctionne aussi sous linux, mais là encore oublie, les binaires sous linux fonctionnent mal, et il faut un compilateur Delphi pour le recompiler...



      Et vous, vous utilisez quoi ?

      • [^] # Re: IDE

        Posté par  (site web personnel) . Évalué à -1.

        KWrite et nautilus
        avec un makefile fait main, c'est plus simple.

      • [^] # Re: IDE

        Posté par  (site web personnel) . Évalué à 1.

        Tu peux aussi essayer code::blocks, qui semble bien fonctionner (je ne l'ai cependant pas encore essayé sur de gros projets)

        Sous linux, ça n'a pas l'air d'etre terrible. D'apres ce que j'ai vu sur le forum, ça compile difficilement et ça ne fonctionne meme pas ou ça plante dans le meilleurs des cas.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # pourquoi spécifiquement ?

    Posté par  . Évalué à 3.

    Quel est l'intérêt de développer un IDE (ou autre) spécifiquement pour gnome, kde ou autres ? Est-ce que ça ne limite pas au contraire les utilisateurs des autres wm qui auraient envie de l'utiliser ?

    Je pose cette question parce que je vois se développer pas mal d'applications spécifiques à gnome, (ggv gpdf) qui semblent en général, (à part pour l'interface un peu plus standard), beaucoup moins bien que leurs prédécesseurs qui marchent sous X (grande jeunesse des applis ?).
    ex :chez moi, gpdf n'affiche pas les pdf issus de latex avec l'encodage T1 alors que xpdf les affiche (pas joliment mais les affiche). De même ggv a l'air moins stable que gv et aura plus tendance à faire des segfault.

    • [^] # Re: pourquoi spécifiquement ?

      Posté par  (site web personnel) . Évalué à 9.

      essaie evince : http://www.gnome.org/projects/evince/(...)

    • [^] # Re: pourquoi spécifiquement ?

      Posté par  (Mastodon) . Évalué à 9.

      Quel est l'intérêt de développer un IDE (ou autre) spécifiquement pour gnome, kde ou autres ? Est-ce que ça ne limite pas au contraire les utilisateurs des autres wm qui auraient envie de l'utiliser ?

      Non, puisqu'il est tout à fait possible d'utiliser une application Gnome avec le WM de ton choix... la seule restriction c'est d'avoir les bibliothèques de Gnome, mais c'est valable pour n'importe quel toolkit, graphique ou non.

    • [^] # Re: pourquoi spécifiquement ?

      Posté par  . Évalué à 2.

      Tout à fait d'accord. Je comprends que les développeurs ne peuvent proposer qu'un type de bibliothèques graphiques/interface par manque de temps, de compétences dans les autres toolkits graphiques ou tout simplement de recul pour adopter un point de vue plus conceptuel. Et après tout, si le but est l'intégration à un desktop, qui permet une bien meilleure gestion de certains aspects, c'est difficilement contournable.

      Mais c'est assez risqué d'intégrer des considérations spécifiques à un environnement graphique (IHM) dans le coeur de gestion. Je dirais même plus, c'est limite intégriste que de ne proposer qu'une interface. On se retrouve dans des situations à la k3b où les gens n'ont les libs qt que pour cette appli. Résultat, une application aussi fondatrice de GTK+ que Gimp est en train de détacher le core de la GUI.

      Après tout, les spécifications FreeDesktop, la gestion unifiée des messages (Dbus?) me semblent permettre une description du comportement d'une application sans référer à un toolkit. Cependant, c'est très récent ce genre de réflexion, et on peut se demander si le port qt de firefox (ou de son rendu, peu importe, je souhaiterais qu'on n'ergote pas sur les termes) ne risque pas de souffrir d'une conception trop conditionnée par GTK+.

      • [^] # Re: pourquoi spécifiquement ?

        Posté par  . Évalué à 3.

        A la rigueur pour GTK+ c'est moins un problème que pour Gnome.

      • [^] # Re: pourquoi spécifiquement ?

        Posté par  (Mastodon) . Évalué à 5.

        Je dirais même plus, c'est limite intégriste que de ne proposer qu'une interface.

        N'importe quoi... bientôt ça va être de l'intégrisme de ne pas répondre aux attentes du monde entier... et mutt qui est en mode texte, c'est de l'intégrisme parce qu'il ne fournit pas d'interface graphique ?

        • [^] # Re: pourquoi spécifiquement ?

          Posté par  . Évalué à -4.

          Désolé, il manquait visiblement un smiley pour faire comprendre qu'il y avait un jeu de mots vaseux, le mot intégrisme étant ici bien sûr abusif ici.

          Résultat, c'est trollesque, et tu es tombé dedans. ;-)

      • [^] # Re: pourquoi spécifiquement ?

        Posté par  (site web personnel) . Évalué à 5.

        >Mais c'est assez risqué d'intégrer des considérations spécifiques à un
        >environnement graphique

        Ben non, meme si il le permet(tu peux faire un projet gnome depuis kdevelop), kdevelop est la avant tous pour les developpeurs KDE! Et il fait bien son boulot meme si je lui reproche quelques problemes d'instabilité.

        >Gimp est en train de détacher le core de la GUI.

        Mwai, ils sont en train de faire comme tout le monde, mettre le maximum de chose dans des libs réutilisables, mais cela ne veut en aucun cas dire que tu aura un gimp basé sur Qt, gimp c'est du gobject(model objet de gtk)!

        >me semblent permettre une description du comportement d'une application
        >sans référer à un toolkit.

        Aucun rapport, c'est juste la pour permettre aux applications sous linux(pas uniquement kde et gnome) de communiquer entre elles. Mais vouloir une application à la fois Qt et Gtk, c'est totalement utopique tellement ces deux toolkit sont différents: pas les meme widgets, comportements, ...

        • [^] # Re: pourquoi spécifiquement ?

          Posté par  . Évalué à 1.

          [HS]En espérant que blockquote fasse ce qu'il semble vouloir dire... Ca se réalise comment des requotes propres sur linuxfr?[/HS]

          Ben non, meme si il le permet(tu peux faire un projet gnome depuis kdevelop), kdevelop est la avant tous pour les developpeurs KDE! Et il fait bien son boulot meme si je lui reproche quelques problemes d'instabilité.

          Je n'utilise et ne connais quasiment pas kdevelop. J'imagine que le K fait référence à son intégration (aheum) au sein de KDE plus que son utilisation de qt.

          Mwai, ils sont en train de faire comme tout le monde, mettre le maximum de chose dans des libs réutilisables, mais cela ne veut en aucun cas dire que tu aura un gimp basé sur Qt, gimp c'est du gobject(model objet de gtk)!

          Ca serait effectivement totalement biscornu d'utiliser les fonctionnalités de la glib et faire du qt en 'backend' graphique. Et vice versa. Et se priver de ces libs de base, c'est vouloir réinventer la roue.

          Aucun rapport, c'est juste la pour permettre aux applications sous linux(pas uniquement kde et gnome) de communiquer entre elles.

          Tu fais donc référence à DBus. Il me semblait que pour l'instant, Gnome et KDE utilisaient leur propre modèle, mais qu'ils avaient décidé de coopérer pour l'utilisation d'une base commune. C'est ce dont je parle: on détache/modularise afin de ne pas limiter une fonctionnalité à un seul environnement - quand celle-ci est disponible sous plusieurs. Après, je me doute bien qu'il y a des différences de modèle insurmontables.

          Mais vouloir une application à la fois Qt et Gtk, c'est totalement utopique tellement ces deux toolkit sont différents: pas les meme widgets, comportements, ...

          Je pensais plus au fait que tu apportes une surcouche (avec tous les défauts que ça peut entraîner) qui permettent d'utiliser un backend au choix.

          Je suis d'accord que, partant sur la glib ou QT, tu peux difficilement choisir autre chose que respectivement GTK+ ou ... (je ne connais pas l'équivalent pour les widgets graphiques liés à QT).

          Je pense que le point de vue du commentaire parent reste valable, à savoir (et à ce que j'ai compris) qu'un minimum de généralisme ne fait pas de mal. Moins il y a de dépendances obligatoires aux libs gnome (GTK+ étant d'une gêne de magnitude différente) ou KDE, mieux ça me semble être (sauf au prix de fonctionnalités, bien sûr).

          • [^] # Re: pourquoi spécifiquement ?

            Posté par  (site web personnel) . Évalué à 2.

            >C'est ce dont je parle: on détache/modularise afin de ne pas limiter une
            >fonctionnalité à un seul environnement

            Non, la il s'agit d'avoir un systeme de message pour unix! Il aurait fallu y venir, Kde ne pouvait pas imposer dcop, enfin je ne pense pas.

            Mais c'est déja la cas sinon, Kde utilise beaucoup de libs en commun avec gnome, librairie souvent développé par des gens de gnome(fribidi, libgsf, ...).

            En fait, on pourrait voir gnome comme une base pour le developpement de Kde :) Nan, je plaisante, mais c'est pourtant pas loin de la vérité pour les librairies de base.

            • [^] # Re: pourquoi spécifiquement ?

              Posté par  . Évalué à 1.

              En meme temps, il est plus facile que Gnome (C) fasse des librairies de base utilisees dans Gnome et KDE plutot que l'inverse, puisque KDE developpe en C++.

      • [^] # Re: pourquoi spécifiquement ?

        Posté par  . Évalué à 1.

        Le problème c'est que les API graphiques intègrent ou sont fortement liées des composants non visuels comme gnome VFS et kioslave.

      • [^] # Re: pourquoi spécifiquement ?

        Posté par  (site web personnel) . Évalué à 6.

        Pour repondre a la remarque originale, il faut bien distinguer deux choses:
        - le toolkit utilise par anjuta
        - les modeles proposes pour faire du dev

        Il est evident que anjuta developpe par et pour Gnome utilise a fond les bibliotheques et toutes les possibilites de Gnome.

        Il est aussi tout a fait naturel que maitrisant bien Gnome et le developpant pour Gnome, les modeles de projets soient des modeles de projets Gnome.

        Mais il ne faut pas y voir la une restriction. Je ne connais pas anjuta mais je serai surpris que l'auteur y aie mis une telle restriction. C'est juste des modeles de projets. Avec le temps et avec les contributions, d'autres modeles seront proposes, qui te permettront de commencer facilement un projet KDE, un projet ncurses, etc.

        Si tu prends KDevelop, le concurrent principal, au debut, il n'y avait que des modeles de projets pour KDE ou pour rien du tout. Maintenant, si tu regardes la listes des modeles en C/C++, tu vois qu'il y a beaucoup de KDE, mais pas mal d'autres choses: du ncurses, du gnome, ...
        http://webcvs.kde.org/kdevelop/languages/cpp/app_templates/(...)

        Donc si tu veux des modeles pour d'autres projets que Gnome, a toi de les proposer.

        Si tu veux que anjuta ne s'integre pas dans Gnome, c'est completement debile.


        > Mais c'est assez risqué d'intégrer des considérations spécifiques à un environnement graphique (IHM) dans le coeur de gestion

        En effet, on devrait faire des applis Gnome qui ne dependent pas de Gnome. Comme ca, pas de considerations IHM dans le coeur de gestion.

        Pour faire une reponse plus intelligente, Gnome (ou KDE), c'est bien plus qu'une IHM. C'est un modele de boucle d'evenement, des classes de bases, un modele graphique et une IHM. Si tu developpes avec Gnome, tu utilises au strict minimum le modele de la boucle d'evenement et le modele graphique. En general, il n'y a pas de raison de se priver des autres elements.


        > On se retrouve dans des situations à la k3b où les gens n'ont les libs qt que pour cette appli.

        Et ? Quel probleme cela pose-t-il ? Avoir Qt pour k3b est une bonne raison d'avoir Qt.

        > Résultat, une application aussi fondatrice de GTK+ que Gimp est en train de détacher le core de la GUI.

        Au contraire, c'est une bonne chose. En separant bien les fonctionnalites de gimp de son interface, on ouvre la possibilite a une nouvelle communaute de contributeur de proposer des nouvelles interfaces. On pourrait donc avoir un gimp en WxWidgets, un gimp en Qt, un gimp en KDE, un gimp en ncurses (j'deconne!).

        Honnetement, je trouve que ca ne devrait pas etre le boulot des developpeurs d'applis de developper le toolkit. Gimp a developpe gtk parce qu'il n'y avait rien qui leur convenait. Si un bon equivalent de Gtk avait ete la a l'epoque, gimp l'aurait utilise.

        Developper un toolkit et developper une appli sont deux choses differentes. On a pas necessairement les memes objectifs

        > Après tout, les spécifications FreeDesktop, la gestion unifiée des messages (Dbus?) me semblent permettre une description du comportement d'une application sans référer à un toolkit.

        Tu fais erreur. DBUS, s'il est adopte par KDE et Gnome permet juste d'envoyer des messages a des applications.

        On n'a pas a l'heure actuelle de description d'une application complete independante du toolkit. Et tu sais quoi ? C'est une bonne chose. Pour faire une bonne application (ergonomique, fonctionelle, rapide, optimisee), il faut tirer au maximum avantage des possibilites du toolkit.

        > Cependant, c'est très récent ce genre de réflexion, et on peut se demander si le port qt de firefox (ou de son rendu, peu importe, je
        > souhaiterais qu'on n'ergote pas sur les termes) ne risque pas de souffrir d'une conception trop conditionnée par GTK+.

        Ben justement, le rendu ne depend pas de Gtk, ce qui a permis de le porter rapidement en Qt.

        Je pense que tu devrais te renseigner plus sur les questions qui te tarabustent, parce que visiblement, tu es peu informe et du dis des betises.

    • [^] # Re: pourquoi spécifiquement ?

      Posté par  . Évalué à 4.

      Tu vois se développer ggv et gpdf ? Ça fait belle lurette qu'ils ne se développent plus ces deux-là. Il sont remplacés par evince http://www.gnome.org/projects/evince/(...) qui est bien mieux que xpdf.

    • [^] # Re: pourquoi spécifiquement ?

      Posté par  (site web personnel) . Évalué à 3.

      >chez moi, gpdf n'affiche pas les pdf issus de latex avec l'encodage T1 alors
      >que xpdf les affiche

      s/gpdf/ghostscript

      Utilise un lecteur pdf basé sur xpdf si tu veux que ca marche, genre kpdf ou evince... Mais c'est clair que ghostscript est assez mauvais et lent!

  • # Pour ceux...

    Posté par  (site web personnel) . Évalué à 6.

    ... qui veulent l'essayer sous Ubuntu: http://www.livejournal.com/users/seedar/10893.html(...)

    Au fait, quelqu'un sait pourquoi Scaffold, l'ancien Anjuta 2 est à l'abandon ?

    • [^] # Re: Pour ceux...

      Posté par  (site web personnel) . Évalué à 5.

      Anjuta a toujours été Anjuta :) Je m'explique :
      - anjuta était développé de son côté et gIDE de l'autre
      - gIDE est à l'origine de gdl (dont son système de docking), gnome-build et gnome-debug (non repris pour anjuta 2, qui a son propre module de debbuging). Il a été écrit au tout début de gtk/gnome 2 avec une architecture à base de plugins.
      - gIDE semblait avoir un bon avenir, mais pratiquement personne ne travaillait dessus. d'un autre côté, Anjuta enchaînait les releases, doucement mais sûrement, ajoutant progressivement des fonctionnalités jusqu'à donner ce que la branche 1.2 est aujourd'hui
      - beaucoup de gens voulait voir une union des efforts de dev, alors ceci a tenté d'être mis en place sous le nom d'Anjuta 2, en portant les outils actuels d'Anjuta sous forme de plugins, mais ça n'a pas trop marché, alors les dév. de gIDE ont appelé leur soft "Scaffold", comme pour se redétacher d'Anjuta, mais personne ne travaille dessus depuis 2/3 ans.
      - un an plus tard, Anjuta 2 alpha apparaît, en ayant porté et amélioré sacrément ses outils, ayant une IHM beaucoup plus conviviale, et surtout en ayant mis à jour et releasé gdl, gnome-build et bientôt glade 3 (pour une intégration de la construction d'IHM) et avec des docs sur son architecture de plugins
      - à noter que cet IDE a pratiquement été réalisé par une seule personne depuis son début, même si quelques contributions commencent doucement à venir :)

      • [^] # Re: Pour ceux...

        Posté par  (site web personnel) . Évalué à 3.

        Ce n'est pas ce que j'ai compris en lisant ça: http://gnomedesktop.org/node/2126(...)

        Pour moi, les équipes de gIDE et Anjuta ont fusionné, ont essayé de faire Anjuta 2 quasiment *from scratch*. Au bout d'un moment, les devs d'anjuta ont préféré partir de la base d'anjuta 1, et récupérer le système de plugins et des bouts d'achitecture de l'anjuta 2 en cours de dev, et se réapproprier le nom d'anjuta 2. L'ancien projet Anjuta 2, qui était celui d'origine développé par les devs anjuta (et surtout ceux de gIDE) a dû être renommé vu que le nom d'Anjuta 2 avait été repris. Ils ont donc renommé l'Anjuta 2 d'origine en scaffold, qui effectivement n'a plus été maintenu.

        • [^] # Re: Pour ceux...

          Posté par  (site web personnel) . Évalué à 1.

          >> Pour moi, les équipes de gIDE et Anjuta ont fusionné, ont essayé de faire Anjuta 2 quasiment *from scratch*
          il n'y a pour ainsi dir eu aucun dév. en commun et donc 0 from scratch. La première étape qu'a faite Naba c'est de renommer toutes les classes gIDE* en Anjuta* avec une batterie de s/gide_/anjuta_/ ... etc pour le changement de nom (c'est là qu'il parle du module CVS anjuta2). Il a ensuite backporté le système de plugins après que la tentative de coopération n'aie pas tellement porté ses fruits.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.