[+] Pas encore dispo pour Gentoo

• [^]Re: Pas encore dispo pour Gentoo

  Posté par Mathieu Pillard (page perso, ) le 16/05/2005 à 23:54. (lien). É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 :)

  • [^]Re: Pas encore dispo pour Gentoo

    Posté par dab () le 17/05/2005 à 00:14. (lien). Évalué à 6.

    Tout à fait, cette version semble être destinée à ceux qui en veulent, à nous de l'utiliser/la tester afin d'arriver à une version stable rapidement.
    Cependant, n'est ce pas étrange de releaser une version alpha & unstable ( dixit l'annonce d'anjuta) en tant que 2.0 ?

    • [^]Re: Pas encore dispo pour Gentoo

      Posté par Mathieu Pillard (page perso, ) le 17/05/2005 à 11:28. (lien). Évalué à 3.

      Ca m'a semblé étrange aussi, mais il convient de relativiser: en dehors du debugger, et du support subversion, anjuta 2.0.0 est plutot stable et complet. Je pense que une partie de la réponse vient du fait qu'il n'y avait pas eu de release depuis longtemps, et donc la sortie de la 2.0, meme si c'est une alpha, permet de montrer que anjuta existe encore, que la nouvelle version que on nous promet depuis longtemps est bien la, etc.
      
      La prochaine version, prevue pour Aout, devrait etre plus stable / terminée. Certaines corrections importantes se trouvent deja dans le CVS.

      • [^]Re: Pas encore dispo pour Gentoo

        Posté par Mathieu Pillard (page perso, ) le 19/05/2005 à 00:32. (lien). Évalué à 2.

        Correction, j'ai trouvé un probleme bizarre. Je chercherais plus amplement demain, mais si certains peuvent tenter de le reproduire, ca m'interesse. En effet, ici anjuta2 fait crasher mon openbox lorsque je maximise sa fenetre.
        
        https://bugzilla.icculus.org/show_bug.cgi?id=2262(...) pour ceux que ca interesse.

  • [^]Ni pour Mandriva

    Posté par Juke (Jabber id, page perso, ) le 17/05/2005 à 00:19. (lien). Évalué à 3.

    Les packager pour cooker ont eux aussi ce genre de problemes et apparement, cela ne compile avec gcc 4

    • [^]Re: Ni pour Mandriva

      Posté par ookaze () le 18/05/2005 à 12:03. (lien). Évalué à 1.

      J'ai tout compilé avec gcc 4.0.0, excepté glade 3, parce que j'installe pas de trucs en CVS sur ma machine.
      Ca a compilé sans problème, excepté un -Werror dans un makefile de Anjuta je crois. Suffit de le virer.

      • [^]Re: Ni pour Mandriva

        Posté par Juke (Jabber id, page perso, ) le 18/05/2005 à 12:36. (lien). Évalué à 2.

        Pour les kamikazes
        
        il y'a des rpms dispos ici:
        http://primates.ximian.com/~sandino/repository/SRPMS/(...)

        • [^]Re: Ni pour Mandriva

          Posté par naurel () le 18/05/2005 à 19:52. (lien). Évalué à 1.

          et pour les gentooistes :
          http://bugs.gentoo.org/show_bug.cgi?id=92758(...)

        • [^]Re: Ni pour Mandriva

          Posté par Juke (Jabber id, page perso, ) le 20/05/2005 à 11:46. (lien). Évalué à 2.

          Le paquet est maintenant dans contrib.
          

IDE

• [^]Re: IDE

  Posté par alberthier (page perso, ) le 17/05/2005 à 08:29. (lien). É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 densmore () le 17/05/2005 à 08:43. (lien). É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 Gniarf () le 17/05/2005 à 15:41. (lien). Évalué à 1.

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

    --
    Windows has no users. It has hostages.

• [^]Re: IDE

  Posté par Mat () le 17/05/2005 à 09:59. (lien). É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 Mildred (Jabber id, page perso, ) le 17/05/2005 à 15:05. (lien). Évalué à -1.

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

    --
    La Roue du Temps

  • [^]Re: IDE

    Posté par Stone Tramo () le 17/05/2005 à 17:45. (lien). É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.

• [^]Re: IDE

  Posté par Étienne Bersac (Jabber id, page perso, ) le 17/05/2005 à 12:46. (lien). Évalué à 3.

  Bonjour,
  
  Sans réveiller les troll, mais s'il existait un mode d'emacs pour gérer les makefile, emacs pourrait gérer les projet, éditer, compiler, debugger et contrôle de version (cvs, svn dans le cvs actuellement ;) ).
  
  Parce que, il n'y a pas photo, emacs explose scintilla et toussa pour l'édition de code source. Ils s'en sort très bien pour le déboguage, la compilation et le déboguage.
  
  Sans blague si un mode existait avec un binding pour éditer l'IHM, un pour ajouter le fichier au projet, etc. emacs serait parfait !!!
  
  Existe-t-il un projet similaire ?

  --
  E Ultreïa !

  • [^]Re: IDE

    Posté par Nap (page perso, ) le 17/05/2005 à 15:11. (lien). Évalué à 5.

    emacs fait-il la completion automatique et l'affichage des méthodes disponibles pour l'objet dans une petite liste déroulante ?

    • [^]Re: IDE

      Posté par Jak () le 17/05/2005 à 15:44. (lien). Évalué à 2.

      J'ai déjà vu un Emacs faire de la complétion (c'est pas complètement, d'ailleurs, le bon terme ? ) automatique, donc, ça, c'est sûr, il sait faire, et sinon, je sais pas.

      --
      « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
      - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)

    • [^]Re: IDE

      Posté par Yusei (page perso, ) le 17/05/2005 à 17:40. (lien). Évalué à 5.

      http://cedet.sourceforge.net/inlinecompletion.png(...)
      
      Il fait tout, si on installe les bonnes extensions. Ici, http://cedet.sourceforge.net/intellisense.shtml(...)

    • [^]Re: IDE

      Posté par C2RIK (page perso, ) le 18/05/2005 à 00:22. (lien). Évalué à 1.

      Il y a ECB qui utilise Bovinator / CEDET pour l'autocomplétion et la navigation dans les classes.
      http://ecb.sourceforge.net/(...)

    • [^]Re: IDE

      Posté par Étienne Bersac (Jabber id, page perso, ) le 18/05/2005 à 12:26. (lien). Évalué à 0.

      alias emacs='emacs -nw' :)

      --
      E Ultreïa !

pourquoi spécifiquement ?

• [^]Re: pourquoi spécifiquement ?

  Posté par champi () le 17/05/2005 à 07:47. (lien). Évalué à 9.

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

  • [^]Re: pourquoi spécifiquement ?

    Posté par nazcafan () le 17/05/2005 à 17:31. (lien). Évalué à 1.

    Merci, je vais essayer ça a l'air prometteur.

• [^]Re: pourquoi spécifiquement ?

  Posté par Yusei (page perso, ) le 17/05/2005 à 07:53. (lien). É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 Kurosu () le 17/05/2005 à 08:45. (lien). É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 neil () le 17/05/2005 à 08:54. (lien). Évalué à 3.

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

  • [^]Re: pourquoi spécifiquement ?

    Posté par Yusei (page perso, ) le 17/05/2005 à 09:04. (lien). É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 Kurosu () le 17/05/2005 à 09:10. (lien). É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 Gniarf () le 17/05/2005 à 16:05. (lien). Évalué à 2.

        ce n'est pas parce qu'il y a un smiley que c'est drôle.

        --
        Windows has no users. It has hostages.

  • [^]Re: pourquoi spécifiquement ?

    Posté par gnumdk () le 17/05/2005 à 09:54. (lien). É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, ...

    --
    Venga Batucada

    • [^]Re: pourquoi spécifiquement ?

      Posté par Kurosu () le 17/05/2005 à 12:11. (lien). É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 gnumdk () le 17/05/2005 à 22:13. (lien). É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.

        --
        Venga Batucada

        • [^]Re: pourquoi spécifiquement ?

          Posté par djano () le 18/05/2005 à 15:48. (lien). É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 bobefrei () le 17/05/2005 à 14:50. (lien). É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 Philippe Fremy (page perso, ) le 18/05/2005 à 06:52. (lien). É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.

    --
    phil.freehackers.org

• [^]Re: pourquoi spécifiquement ?

  Posté par Bestel Xavier (page perso, ) le 17/05/2005 à 08:52. (lien). É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 gnumdk () le 17/05/2005 à 09:46. (lien). É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!

  --
  Venga Batucada

  • [^]Re: pourquoi spécifiquement ?

    Posté par philou (page perso, ) le 17/05/2005 à 12:29. (lien). Évalué à 2.

    > 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!
    
    Sauf que Gv est rapide et propre.

    • [^]Re: pourquoi spécifiquement ?

      Posté par gnumdk () le 17/05/2005 à 22:16. (lien). Évalué à 1.

      http://www.mta.info/nyct/maps/subwaymap.pdf(...)
      
      Ben tu m'ouvres ca avec gv, tu compares avec kpdf(un peu plus rapide que xpdf) et on en reparle hein de la rapidité de gv(qui utilise ghostscript)...

      --
      Venga Batucada

Pour ceux...

• [^]Re: Pour ceux...

  Posté par Stéphane Démurget (page perso, ) le 17/05/2005 à 11:15. (lien). É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 liberforce (Jabber id, page perso, ) le 17/05/2005 à 13:39. (lien). É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 Stéphane Démurget (page perso, ) le 19/05/2005 à 11:16. (lien). É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.