Sortie de KDevelop 4.0

Posté par  (site web personnel) . Modéré par Bruno Michel.
Étiquettes :
34
1
mai
2010
KDE
Après plus de 3 ans de travaux, la version 4.0 de KDevelop, l'environnement de développement intégré de KDE, est enfin disponible.

Cette nouvelle version est une refonte complète de la version 3.0, et apporte énormément de nouvelles fonctionnalités, dont une intégration poussée avec Kate (éditeur de texte de KDE) et Okteta (visionneuse de fichiers binaires).

Se trouvent également au menu des nouvelles fonctionnalités un environnement totalement personnalisable, et une architecture modulaire (tout KDevelop n'est qu'un ensemble de plugins). Avec cette version, KDevelop prouve qu'il est possible de créer un environnement de développement puissant tout en restant assez simple et (relativement) léger.

La seconde partie de la dépêches contient une liste des fonctionnalités phares de cette version. Voici la liste des différentes fonctionnalités de cet environnement, qui mérite qu'on s'y intéresse de près.

Intégration complète à KDE 4

KDevelop est intégré à KDE 4 aussi bien visuellement que côté fonctionnalités. Il utilise son module d'édition de texte (Kate), permet d'accéder aux fichiers depuis le réseau en utilisant les KIO, et propose un petit terminal basé sur Konsole.

Gestion des projets

KDevelop est capable d'ouvrir plusieurs projets en même temps, ainsi que de naviguer dedans. Il permet, pour les langages supportés (C++ et PHP de base, plein d'autres grâce aux greffons), de retrouver le fichier contenant la déclaration d'une fonction.

Ces projets peuvent se baser sur CMake (utilisé par KDE et d'autres), les Autotools (utilisés par beaucoup de monde), ainsi que QMake (applications Qt pures) avec un greffon.

La gestion des projets est assez complète, et permet, depuis l'interface graphique, de compiler et lancer les différents exécutables du projet (avec reconstruction de bibliothèques, nettoyage, etc).

Intégration de GDB

Les projets lancés peuvent être débogués grâce à GDB, qui depuis la version 7 et avec un petit script facilite grandement le débogage d'applications Qt.

Des points d'arrêt peuvent être placés, on peut sauter des instructions, etc. Un point intéressant est que lors du débogage, l'interface de KDevelop s'adapte pour proposer des fonctionnalités plus adaptées.

En effet, on peut trouver en haut à droite de sa fenêtre trois onglets : "Code", "Débogage" et "Revue de code", chacun permettant de transformer l'interface pour qu'elle soit la plus adaptée possible à un style (programmation, débogage pour gestion des révisions et des patches).

Coloration syntaxique et compréhension des sources

La coloration syntaxique de KDevelop est très complète, et se base sur une solution maison, appelée DUChain, vantée comme étant largement plus performante que les CTags.

Cette architecture permet de parser le code source des programmes développés et des en-têtes utilisées, et comprend une grosse partie de la syntaxe.

Ainsi, toutes les opérations de refactoring (par exemple, le changement de nom d'une fonction, avec adaptation de tous les fichiers du projet automatiquement) sont facilitées et très efficaces, même si les fonctions supportées ne sont pas encore très nombreuses.

La coloration syntaxique basique est supportée pour tous les langages compris de Kate (une cinquantaine, dont le C, C++, Python, PHP, Javascript, les langages basés sur XML, l'assembleur (y compris VHDL et autres), les variantes du SQL, le Perl, le fichier xorg.conf, etc).

Les langages C, C++, CMake et PHP disposent d'une coloration plus poussée (variables en couleur, erreurs de compilation mises en avant) et de la compréhension du code. D'autres langages (Python, Ruby, CSS, HTML, etc) sont plus ou moins supportés par des greffons externes.

Support des gestionnaires de révision

Les gestionnaires de révision comme Git, Subversion, Mercurial et Bazaar sont supportés par KDevelop, et permettent de consulter les patches entre deux versions, de revenir à la version précédante d'un fichier, de mettre à jour son dépôt, d'envoyer ses modifications, etc.

Ces fonctionnalités prennent place dans l'onglet «Revue de code» en haut à droite de la fenêtre de KDevelop.

Intégration de la documentation

La documentation dans KDevelop est disponible presque partout. Il est possible d'utiliser un panel affichant la documentation de Qt par exemple, et également d'utiliser les tags Doxygen présents dans les sources et les en-têtes utilisées.

Foire aux screenshots

Rien de mieux que de beaux screenshots pour mettre l'eau à la bouche et présenter les dernières fonctionnalités. Autant en profiter que KDevelop est relativement élégant.
  • Fenêtre principale de KDevelop : Organisée en panneaux, avec une zone centrale pour les fichiers. Le menu est découpé en section (on aime ou on n'aime pas), avec les trois onglets visibles en haut à droite. Ce screenshot est un peu compact, mais sur un écran 1280x1024, ça passe impeccablement (sur du 1024x768 aussi normalement, c'est un peu plus grand que ce screenshot).

  • Auto-complètement du C++ : Le C++ est le langage de référence pour KDevelop (langage principal de KDE), et est entièrement supporté, malgré sa complexité. Ici, vous pouvez observer l'auto-complètement proposé par KDevelop. Cliquer sur une fonction affiche des informations comme le couple déclaration/définition, qui l'utilise, etc.

  • Création automatique des implémentations en C++ : KDevelop permet d'utiliser son infrastructure d'auto-complètement pour créer le squelette de fonctions C++ en connaissant leur signature (dans l'exemple : la fonction du haut est le résultat, en dessous tout ce que le développeur a à taper).

  • Affichage des utilisations d'une fonction : La compréhension du code permet de voir où une fonction est utilisée, dans quelles conditions, etc. L'interface est encore assez claire par rapport aux informations fournies, même si c'est vrai qu'il faut un peu se concentrer pour la lire.

  • Refactoring de code : Pour le moment à peu près la seule opération de refactoring disponible, mais on est déjà bien content quand on peut l'utiliser !

  • Support les fichiers CMake : CMake, un outil de construction de sources, est supporté par KDevelop qui permet de compléter automatiquement différents aspects de son langage de script.

  • La documentation dans tout KDevelop : KDevelop propose au développeur une quantité impressionnante de documentation, au moyen d'un panneau à droite (qu'on peut bien entendu replier), ou directement dans l'infrastructure d'auto-complètement.

  • Greffon Git : L'intégration de Git directement dans KDevelop permet de se passer de console pour les opérations basiques.

  • Revue de code et patches : KDevelop, au moyen de son greffon Git, supporte la création de patches, et permet de comparer un fichier avec sa version dans le dépot.

Conclusion

KDevelop est vraiment un environnement de développement à tester. Il est capable de rivaliser avec les plus grands, et propose encore plein de choses non présentées ici (comme par exemple la création de projets à partir de templates). Chaque greffon nécessiterait toute une dépêche pour le décrire (savez-vous que le greffon de support PHP supporte l'auto-load de PHP pour fournir l'auto-complètement des classes et fonctions utilisées ainsi ?), et le tout est particulièrement bien intégré.

Maintenant, il est vrai que c'est une version en .0, donc pouvant souffrir de quelques problèmes. Heureusement, ce n'est pas comme KDE 4.0 (ils ont compris maintenant, rassurez-vous !), et KDevelop est largement utilisable depuis près d'un an, sans plantages intempestifs.

Il est donc temps de faire chauffer les compilateurs, en attendant une intégration dans vos distributions préférées.

Aller plus loin

  • # J'aime

    Posté par  . Évalué à 3.

    L'autocomplètement et tout autant l'autocomplétion
  • # Mais surtout...

    Posté par  . Évalué à 8.

    Le mode vi !

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Mais surtout...

      Posté par  . Évalué à 3.

      Par contre le mode Emacs demande un redémarrage pour pouvoir booter se lancer. Comment ça, non ?!
      • [^] # Re: Mais surtout...

        Posté par  . Évalué à 5.

        Rien à voir, c'est juste qu'il faut lancer KDevelop dans emacs sous la forme d'un plugin
  • # Comparaison avec Eclipse

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

    Je serais curieux de l'essayer pour comparer avec Eclipse qui actuellement me satisfait (développement C et un peu de C++, occasionelement Java). Les outils de refactoring me fait penser à ce que Eclipse fait déjà assez bien.
    Ce qui ne marche pas très bien avec eclipse, c'est l'intégration avec git (obligé de devoir relancer un refresh complet lorsque l'on change de branche) et les raccourcis claviers (j'ai des difficultés avec certaines fonctionnalités comme la recherche de texte).

    L'intégration git me semble prometteuse, et si c'est de meilleure qualité que kdevelop 2 et 3 que j'ai essayés et abandonnés, j'suis prêt à switcher.
    • [^] # Re: Comparaison avec Eclipse

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

      Personnellement, je préfère éviter eclipse à cause de sa lourdeur, mais ce qui m'attire le plus chez lui, c'est la puissance de la colorisation syntaxique et du complètement, qui sont partiellement sémantique,(basés il me semble sur l'utilisation de gcc) donnant ainsi un bien meilleur retour au développeur.

      J'ai l'impression que les développeurs de KDevelop ne sont pas allé aussi loin, et c'est dommage pour une version majeure.
      • [^] # Re: Comparaison avec Eclipse

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

        La communication ne me semble pas non plus au rendez-vous. A part cette page sur linuxfr (que d'ailleurs je trouve super !), le site de kdevelop parle encore de la version 3.5 et ne donne pas de lien pour télécharger kdevelop4 (merci pour les liens d'ailleurs).

        Petite surprise au premier démarrage, pas de bouton "nouveau projet". Il ne faut pas oublier de lancer kbuildsycoca4 (quoi que ça fasse) pour recharger les plugins.

        Dans les points positifs, je viens d'importer mon projet basé sur cmake (petite pub: www.libssh.org), l'importation s'est très bien déroulée, compilation aussi, et les menus/editions ont l'air d'être bien plus fluides qu'avec eclipse.

        petite déception, absence du plugin git dans le pack officiel. Je ne sais pas encore où le trouver et le vide sidéral du site de kdevelop n'aide pas.

        Pour les ubuntusers, les packages à installer avant de compiler sont
        kdebase-workspace-dev kdelibs5-dev
        • [^] # Re: Comparaison avec Eclipse

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

          Bon je réponds à moi-même:
          svn co svn://anonsvn.kde.org/home/kde/trunk/playground/devtools/kdevelop4-extra-plugins/
          • [^] # Re: Comparaison avec Eclipse

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

            Oui effectivement la news ne le dit pas assez mais php et phpdoc est actuellement le seul plugin considéré comme relativement stable.

            Les autres (git, css, ...) en sont encore loiiiiiin... mais les choses évoluent vite avec kdevelop.

            Puis sinon au niveau du GSOC un des auteur du plugin php et d'une partie de kdevelop devrait se lancer dans la débronsonification de Quanta+ l'editeur web kde.

            Celui-ci devrait être relativement semblable à kdevelop mais en enlevant les brols spécific au c++ et en donnant un peu d'amour au plugins plus orienté web ( css, html, et si le temps le permet js).
      • [^] # Re: Comparaison avec Eclipse

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

        Perso, je préfère largement Eclipse.

        Je ne le trouve pas si lourd, à partir du moment où tu n'installes pas tous les plugins de la terre.

        Au niveau des astuces pour le quotidien, je trouve qu'Eclipse, c'est la rolls. Il y a plein de raccourcis et d'outils de refactoring qui sont indispensables quand tu y as gouté.

        Pour Git, la prochaine version d'Eclipse 3.6 proposera le plugin eGit (fait en partie par des gars de Google).

        Pour l'aspect plugin, je trouve cela délirant que les outils Linux ré-inventent tous cette notion de plugins. C'est la grosse mode de rendre à base de plugins, mais surtout, il ne faut pas réutiliser ce qui existe déjà. Dommage pour les développeurs car avoir un modèle commun de pluginisation serait top.
        Pour info, il y a OSGi qui fait cela depuis des années, et qui le fait bien (c'est utilisé dans les telephones portables, dans Eclipse, dans les serveurs JavaEE, dans des composants embedded, etc ...)
        • [^] # Re: Comparaison avec Eclipse

          Posté par  . Évalué à 8.

          T'as raison c'est pas le bordel au moins avec eclipse. Genre installer le plugin svn c'est trivial quand ça marche (parce que j'ai pas encore réussi).

          L'avantage d'OSGi c'est que c'est pas une usine à gaz monstrueuse, c'est interopérable entre langage et c'est tellement simple à utiliser que 80% des plugins eclipse sont mal fichu.

          C'est vrai il y en a qui devrait prendre exemple....

          ctags c'est bien le genre de projet tout récent qui essaie de reconstruire la roue (depuis 20 ans...).


          Bref ce n'est pas parce que les développeurs eclipse ont fait des choses plus ou moins bien dans leur coin qu'il faut à tout prix se baser sur eux.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Comparaison avec Eclipse

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

            Je ne parlais spécialement d'Eclipse, mais bien de tenter d'unifier le modèle de plug-in. Et le seul standard que je connais, et qui est multi-plateformes et non spécifique à un soft, c'est OSGi. Si tu en connais un autre, je suis preneur.

            Et si tu as des idées pour simplifier OSGi, je pense qu'ils seront preneurs de tes lumières.

            Image si les descripteurs de tes plug-ins Pidgin, FIrefox, OpenOffice, etc ... avaient tous la même syntaxe de description des dépendances ? Ca ne me semble pas inatteignable (en rêvant un peu), et sacrément utile pour le développeur.
            • [^] # Re: Comparaison avec Eclipse

              Posté par  . Évalué à 3.

              OSGi n'est pas portable, il ne fonctionne que sur la JVM (et encore je ne suis pas sur que ça marche avec scala ou closure).

              Donc libre à toi de penser que toutes les applications devraient être écrites dans le même langage, mais ça ne te mèneras nul part.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Comparaison avec Eclipse

                Posté par  . Évalué à 4.

                Pourquoi être si défaitiste ?

                Je trouve son idée très intéressante au contraire !

                Et plutôt que de prendre OSGi comme norme, peut être faudrait-il définir une norme dont OSGi est l'implémentation Java ?

                Je ne connais pas trop OSGi, mais d'après http://fr.wikipedia.org/wiki/OSGi on peut avoir des Bundle en C/C++ aussi. Seul le framework doit être en Java.

                Y'aura bien quelques différences d'implémentation et quelques différences fondamentales (la structure d'un Jar et d'un So sont quand même assez différentes je suppose)

                Mais de là à être aussi catégorique ("OSGi c'est pour Java, c'est donc pas intéressant") je trouve que c'est un peu hâtif comme jugement. A moins que tu n'aies perdu beaucoup de temps à étudier OSGi et que tu as justement été déçu par ce blocage Java, ce qui expliquerait ton amertume.
                • [^] # Re: Comparaison avec Eclipse

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

                  Si c'est juste pour définir une norme de plugins... OSGi est hyper sur-dimensionné, regarde tout ce qu'il intègre... c'est une usine à gaz. Ca répond à un besoin de développements industrialisés, moyens importants et procédures très strictes, déploiement à grande dimension. Mais ça ne peut pas répondre aux besoins courants, trop lourd à utiliser lorsqu'on a des besoins simples.
                  Dans le même esprit, il y a CORBA, qui avait aussi défini pas mal de choses pour l'intégration de composants, et là en multi-plateforme multi-langages. C'est utilisé, mais très peu, même problème qu'OSGi... le coût d'accès pour les développeurs est élevé.

                  Et perso, je ne suis pas sûr que dans ce domaine on puisse trouver un logiciel qui réponde à l'hétérogéniéité des besoins... sans être une usine à gaz qui rebutera beaucoup de développeurs.

                  Tu veux des plugins avec du graphiqme, utilise par exemple les KParts, justement, il y a un portage de KDE sous Windows (si tu recherches le multi-plateformes - bon, je ne sais pas où ils en sont, pas plus que le portage sous Mac s'il y en a un)
                  Tu as juste besoin que des composants communiquent, regarde DBus.

                  Encore un autre, tu cibles COM/DCOM/ActiveX, et tu utilises Wine ou de la virtualisation :-) [peut-être plus facile d'abord que OSGi pour un développeur]

                  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

        • [^] # Re: Comparaison avec Eclipse

          Posté par  . Évalué à 3.

          Ça change quoi que ce soit « des gars de Google » ? C'est quoi l'intérêt d'un plugin git ? Baisser sa productivité en utilisant sa souris plutôt que son clavier ?

          DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

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

            • [^] # Re: Comparaison avec Eclipse

              Posté par  . Évalué à 2.

              D'un autre côté, si tu utilises git sans comprendre comment ça marche, ça ne va
              rien t'apporter. J'imagine que tu es du genre à considérer que git est un
              subversion qui te permet de commiter en local…
              • [^] # Re: Comparaison avec Eclipse

                Posté par  . Évalué à 6.

                Parce que le fait de devoir taper la commande plutot que la cliquer te fait mieux comprendre le fonctionnement ?
                • [^] # Re: Comparaison avec Eclipse

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

                  Faut dire aussi que git est tellement intuitif et bien fichu que si tu ne te farcis pas trois tutoriaux et quelques kilometres de doc pour comprendre comment ça marche tu vas vite tourner en rond et t'enerver
              • [^] # Commentaire supprimé

                Posté par  . Évalué à -2.

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

                • [^] # Re: Comparaison avec Eclipse

                  Posté par  . Évalué à 4.

                  On 02/May - 21:35, Riendf wrote:
                  > J'imagines que tu es du genre a deduire que le seul exemple qu'on donne et la
                  > seule commande qu'on connait d'un outil......

                  Ta phrase étant syntaxiquement incorrecte, je ne la comprends pas.

                  > Je te reexplique, si meme sur les commandes de bases que tu fais le plus
                  > souvent, t'as du mal a rentabiliser ton temps d'apprentissage, c'est que
                  > question productivite, y a bien d'autre chose a faire....

                  Parce que justement, l'intérêt n'est pas dans les commandes de base, mais bien
                  dans le fonctionnement de git. Maintenant, soit ton plugin graphique n'interface
                  que les commandes de base, et tu perds toute la puissance (tu seras quand même
                  obligé de passer en commande), soit tu peux tout faire avec, et je n'ose
                  imaginer la complexité de l'interface (davantage que les commandes mêmes).

                  > C'est le meme probleme que de lancer un calcul dont tu sais qu'il va te
                  > prendre un an, alors que dans 6 mois il te prendra 2 mois evolution du
                  > materiel oblige. la productivite se mesure en fonction du temps gagne au
                  > total, et ca comprends le temps d'apprentissage.

                  Eh bien justement, je peux te dire que j'ai bien rentabilisé mon temps
                  d'apprentissage de git, tout comme celui de vim, etc.

                  > Globalement, il est rare de rentabiliser l'apprentissage de commandes, a moins
                  > de ne faire que ca. Sans parler de ces commandes qui ne servent qu'une
                  > fois....et qu'on aura oublie ou qu'elles seront devenues obsoletes la
                  > prochaine fois que l'on a a s'en servir.

                  J'ai rarement lu de telles conneries.

                  Tu vois par exemple, pas plus tard que vendredi, j'ai écris un alias tout bête:

                  sr = !sh -c 'git fetch $1 && git show-branch --current $1/\\*' -

                  À utiliser « git br someone », il récupère les branches du dépôt public d'une
                  personne, et utilise show-branch pour les comparer avec les tiennes. Tu sais
                  ainsi aisément si il y a des commits à merger.

                  Je n'ose imaginer comment tu pourrais faire ça avec ton plugin graphique. C'est
                  dingue le temps fou que je gagne grâce aux commandes.
                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 3.

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

                    • [^] # Re: Comparaison avec Eclipse

                      Posté par  . Évalué à 1.

                      > Alors ton alias hein.....j'en vois meme pas l'utilite.

                      Eh bien c'est un cas prévu par ton plugin soit, mais tu n'as pas compris le fond
                      de ma pensée qui est qu'on peut facilement étendre l'usage qu'on a de git grâce
                      aux alias et à la ligne de commande, ou en faisant de scripts, là où tu ne
                      pourras jamais scripter une interface graphique.
                      • [^] # Re: Comparaison avec Eclipse

                        Posté par  . Évalué à 8.

                        Certe, mais ce qu'il te dis là c'est que ton script magique, il résoud un besoin commun que d'autres ont pas attendu pour résoudre de manière efficace.

                        Et que des besoins communs comme ça, t'as pas forcément besoin d'un long apprentissage d'un outil plus ou moins tordu pour les résoudre. Donc il préfère utiliser les solutions déja prévues plutôt que devoir se plonger dans l'outil pour écrire un script pour faire la même chose ... et qu'en pratique et pour la plupart des gens il n'y a pas forcément nécessité à aller plus loin.
                  • [^] # Re: Comparaison avec Eclipse

                    Posté par  . Évalué à 4.

                    sr = !sh -c 'git fetch $1 && git show-branch --current $1/\\*' -

                    À utiliser « git br someone », il récupère les branches du dépôt public d'une
                    personne, et utilise show-branch pour les comparer avec les tiennes. Tu sais
                    ainsi aisément si il y a des commits à merger.


                    Tu pourrais aussi taper "hg in".
                    • [^] # Re: Comparaison avec Eclipse

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

                      Donc plutôt que de créer un alias, il faut utiliser un système avec des gros manques ?

                      plus sérieusement, hg est pas trop mal, mais il manque un truc essentiel pour moi : les branches locales nommées
                      C'est un casse-tête sans nom ce truc, alors que c'est si simple sous git...

                      Pour avoir testé git, hg et bzr pour virer nos svn qui nous emmerdent (gestion de branches, merges, commit locaux, distants, etc) je reviens toujours vers git, et pourtant j'ai à chaque fois cru que les autres allaient finir par me convaincre ... mais non ...
                      • [^] # Re: Comparaison avec Eclipse

                        Posté par  . Évalué à 3.

                        Tu pourrais développer un peu tes griefs, parce que les branches nommées existent avec Hg aussi et je ne vois pas ce qu'il y a de complexe dans leur gestion:
                        http://mercurial.selenic.com/wiki/NamedBranches
                        • [^] # Re: Comparaison avec Eclipse

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

                          oui mais il fallait lire complètement la phrase : les branches locales nommées

                          C'est l'un des points majeurs qui fait que je n'ai pas choisi hg.

                          (bon ok, désormais j'utilise un peu moins les branches locales depuis que j'utilise stg)
                          Les branches locales nommées sont pour moi la base de l'utilisation d'un truc comme git, hg, etc. Leur manque est vraiment dommage.

                          Si on prend l'explication du wiki de hg, on a :
                          Named branches are nice for long-lived branches (eg stable vs development). But sometimes you want to create short-lived branches, perhaps to develop a feature. Once the code has matured to the point where it is ready for mainline, the history of its development is often just uninteresting clutter. The usual answer is to use Mercurial's nice lightweight clones. But even these require duplication of the working directory for each branch, and often other setup work (configure runs etc).

                          Donc voilà, l'explication initiale c'est : "utilisez des clones". C'est bien beau sur le papier, mais ça veut dire que switcher entre deux branches c'est galère, surtout lorsqu'on bosse dans un IDE là où les branches fonctionnent. En fait, tout ce qu'il faut c'est gérer des branches, qu'elles soient locales ou non ça ne devrait rien changer quant à leur utilisation de base.
                          • [^] # Re: Comparaison avec Eclipse

                            Posté par  . Évalué à 2.

                            C'est pas bien d'extraire un paragraphe d'un contexte et de cacher le reste;)

                            La page en question est :
                            http://mercurial.selenic.com/wiki/LocalbranchExtension
                            Cette extension traite donc ta demande.

                            Maintenant, même sans ça, je vais essayer de mieux comprendre car je ne connais pas assez git.
                            Je suppose que ce que tu veux dire c'est que git permet de cloner des branches sélectivement.

                            Mais avec Hg, Si tu crées une branche nommée avec une convention pour indiquer qu'elle est temporaire, tu peux switcher entre 2 branches comme avec Git, non ?

                            Après ceux qui pullent ton repository, récupéreront ta branche mais comme elle est nommée autrement que la principale, il ne seront pas pollués pour les merges (les seules heads sont celles de la branche principale)

                            Donc à part que ca fait gonfler un peu ton repository c'est pas gênant non ?


                            L'autre solution consiste à cloner ton repository tranquillement dans ton coin et réincorporer dans le repository propre qui matche la branche principale
                            Là ton objection, c'est: oui mais avec mon IDE ca marche pas car y'a pas de branches entre lesquelles switcher.
                            Et là j'ai envie de répondre que si tu prends un IDE dédié à git, il est évident qu'il n'est pas adapté à un autre SCM.
                            Ton IDE doit te permettre de switcher simplement entre repository et merger facilement.
                            C'est une problématique de l'outil. Le plugin Mercurial pour Eclipse a bien évolué et est bien adapté. Tout comme le plugin EGit prend en compte les spécificité de Git.

                            Mais même sans ça je pense qu'il n'est pas impossible que Mercurial puisse cloner un jour des branches plutôt que des repositories

                            Par contre, moi je trouve qu'à l'usage la métaphore de Mercurial (inspirée de Monotone) est bien plus pratique à l'usage que celle de Git.
                            Une branche est en fait un genre de graphe de noeuds étiquetés. A un moment donné il peut y avoir plusieurs têtes. Le but du jeu est simplement de toutes les merger pour n'en obtenir qu'une seule.

                            Avec Git tu as à chaque fois une branche nommée à créer ou créée en automatique comme mirroir d'une autre distante, ce qui fait que tu n'as qu'une succession linéaire de noeud . Dès que tu veux repartir d'une révision pour tester un petit truc tu dois recréer une branche, la nommer au lieu de simplement créer un nouveau noeud (révision). Tu dois jongler entre toutes tes branches, celles des autres et au final ca devient plus compliqué de savoir ce que tu as oublié d'intégrer que de simplement identifier les heads orphelines de ton unique branche.
                            Je suis pas sûr d'avoir été clair.
                            • [^] # Re: Comparaison avec Eclipse

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

                              > Cette extension traite donc ta demande.
                              ha oué mais non, pour l'avoir essayée plus d'une fois, elle est juste ... peu utilisable (pour pas dire encore moins)

                              > Après ceux qui pullent ton repository
                              Que ceux qui pullent mon repository aient accès à mes branches, ok. Mais c'est surtout que je ne veux pas forcément pusher des branches.
                              Et si je ne les push pas, lors des merges Hg le fera pour moi ... et ça, ben non merci (outre que c'est plus chiant à gérer)

                              > comme elle est nommée autrement que la principale, il ne seront pas pollués pour les merges
                              Ca evidemment, il faut bien nommer ce qu'on fait, mais ça n'a finalement pas grand chose à voir avec la problématique.

                              > Donc à part que ca fait gonfler un peu ton repository c'est pas gênant non ?
                              Ca, ça dépend _vraiment_ du nombre de branches locales que tu gère...
                              Sur un des projets sur lequel je bosse, j'ai environ 25 branches locales pour quelques branches distantes. Les branches locales sont dédiées à certains bugs, améliorations, tests, etc.
                              Pour beaucoup, je n'ai ni l'envie, ni le besoin de les pusher.
                              (et pour ce qui est de "sauvegarde" de mon taff ... ben j'ai des sauvegardes)

                              > cloner ton repository tranquillement dans ton coin et réincorporer dans le repository propre qui matche la branche principale
                              > Là ton objection, c'est: oui mais avec mon IDE ca marche pas car y'a pas de branches entre lesquelles switcher.

                              Je me suis peut-être mal exprimé.
                              L'objection pour l'IDE, c'est que la partie la plus visible. Mon IDE n'est pas dédiée, adapté ou autre à git, c'est juste un IDE. La plupart du temps je suis en réalité dans emacs d'ailleurs...

                              Je ne veux pas gérer plein de clones dans tous les sens, je n'ai aucune raison d'avoir un clone "local" et un clone "propre pour pusher" alors que j'en ai juste pas besoin et que ça me complexifie la vie.

                              Concernant le dernier paragraphe, je pense par contre que c'est plus galère sous Hg, justement car tu ne les nommes pas. La confusion est souvent plus facile.

                              > Je suis pas sûr d'avoir été clair.
                              Ca va ;) c'est toujours complexe ces problématiques de toute façon.


                              Le problème, je trouve, c'est que je voudrais pouvoir avoir des branches locales bien gérées. Mais ... en gros on m'explique comment m'en passer. Et c'est assez dommage je trouve (même s'il peut y avoir des raisons derrière)
                              Alors que de l'autre côté, on m'explique qu'il faut user et abuser des branches, y compris locales
                              • [^] # Re: Comparaison avec Eclipse

                                Posté par  . Évalué à 2.

                                OK je comprends mieux ton besoin.

                                En résumé, tu voudrais pouvoir faire des push/pull sélectif, peu importe que ce soit lié à un branche ou non.
                                http://www.selenic.com/pipermail/mercurial/2009-August/02723(...)


                                Mais si tes 25 branches sont publiques pour 1 seule distante, c'est quoi le pb:

                                - Le fait que ceux qui pullent depuis le repository central voient les 25 branches supplémentaires y compris dans les manips au travers de leur IDE
                                - l'overhead au niveau des synchros

                                C'est bien ça ?

                                Dans ce cas, je pense que ca couterait pas trop cher de rajouter une metadonnée dans Hg qui associe à une branche une propriété "privée et un user propriétaire.
                                Après il suffit simplement que les interfaces les ignorent (CLI, IHM, ...)

                                Ca fait un peu comme la "lock obsolete" de branches avec Clearcase. Ca supprime virtuellement la branche.
                                • [^] # Re: Comparaison avec Eclipse

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

                                  Salut - je débarque un peu dans votre discussion, et je découvre les DVCS et leur utilisation, mais est ce que l'extension "bookmark" de mercurial ne correspond pas au besoin de ces "branches locales ala git" ?
                                  • [^] # Re: Comparaison avec Eclipse

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

                                    J'avais testé, mais il y a un _gros_ problème avec (en tout cas c'est se dont je me souviens)
                                    Ce n'est qu'un marque page. Autrement dit, si je veux faire démarrer deux branches à un commit particulier ... ben je peux pas, c'est la même branche.
                                    Enfin je crois que c'était ça le problème, dans tous les cas j'ai été déçu. J'ai aussi testé une autre extension, faudrait que je la retrouve, qui faisait ça un peu mieux, mais pas convaincu non plus.
                                    C'est beaucoup une histoire de façon de faire, c'est pour ça que hg n'est pas moins bon que git, mais qu'en tout cas git me convient et non hg malheureusement (car hg a d'autres avantages)
                                • [^] # Re: Comparaison avec Eclipse

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

                                  J'ai essayé de faire un petit exemple représentant mon "problème"
                                  J'ai tenté de le faire, à l'identique, en git et hg. J'ai commencé par git car c'est ce que j'utilise en temps normal

                                  git
                                  {Exp} mkdir -p {hg,git}/dist
                                  {Exp} cd git/dist
                                  {dist} git init
                                  {git:master dist} echo "file1" > file1
                                  {git:master ~ dist} git add file1
                                  {git:master + dist} git ci -m "add file1 from master"
                                  {git:master dist} cd ..
                                  {git} git clone dist local && cd local
                                  {git:master local} git co -b test
                                  {git:test local} echo "from test branch" >> file1
                                  {git:test # local} git ci -a -m "add content from test branch"
                                  {git:test local} git co master
                                  {git:master local} echo "file1, from master" > file1
                                  {git:master # local} git ci -a -m "update file1 from master"
                                  {git:master local} git merge test
                                  {git:master # merge local} [fix conflict]
                                  {git:master # merge local} git add file1
                                  {git:master + merge local} git ci -m "merge test branch"
                                  {git:master local} git branch -d test
                                  {git:master local} git push
                                  {git:master local} cd ../dist
                                  {git:master dist} git branch -a
                                  * master
                                  {git:master dist} git lg
                                  * fd45db0 - (master) merge test branch
                                  |\
                                  | * cc495d5 - add content from test branch
                                  * | 1de1ae5 - update file1 from master
                                  |/
                                  * 4640d4e - add file1 from master


                                  hg
                                  {Exp} cd hg/dist
                                  {dist} hg init
                                  {hg:default dist} echo "file1" > file1
                                  {hg:default ~ dist} hg add file1
                                  {hg:default + dist} hg ci -m "add file1 from default"
                                  {hg:default dist} cd ..
                                  {hg} hg clone dist local && cd local
                                  {hg:default local} hg branch test
                                  {hg:test local} echo "from test branch" >> file1
                                  {hg:test # local} hg ci -m "add content from test branch"
                                  {hg:test local} hg up default
                                  {hg:default local} echo "file1, from default" > file1
                                  {hg:default # local} hg ci -m "update file1 from default"
                                  {hg:default local} hg merge test
                                  {hg:default # local} [fix conflict]
                                  {hg:default # local} hg resolve -m file1
                                  {hg:default # local} hg ci -m "merge test branch"
                                  {hg:default local} hg up test && hg ci --close-branch -m "close branch" && hg up default
                                  {hg:default local} hg push -b default
                                  abort: push creates new remote branches: test!
                                  (use 'hg push -f' to force)
                                  {hg:default local} hg push -b default -f
                                  {hg:default local} cd ../dist
                                  {hg:default dist} hg branches
                                  default 3:d8720e9dd3fa
                                  test 1:b70988680c82 (inactive)
                                  {hg:default dist} hg log [ok c'est pas la vrai commande, mais hg view
                                  en texte donnerait : ]
                                  * 3 - (tip) merge test branch
                                  |\
                                  | * 2 - (test) add content from test branch
                                  * | 1 - update file1 from default
                                  |/
                                  * 0 - add file1 from default


                                  Résultat
                                  Pour git, aucune mention de la branche 'test'
                                  On a bien l'information que ça vient d'une branche, ou pas en fait, et on s'en cogne. Toute l'information nécessaire est là, et c'est le principal, sans être pollué par autre chose.
                                  Si mon dépot est public, personne ne voit test, ni sait qu'elle existe, ni comment, etc, et c'est le but, se concentrer sur le résultat.

                                  Pour hg, on a bien notion de 'test', la branche doit être créée, etc. C'est plus génant, peut-être pas pour un projet avec 1 branche locale, mais pour un projet avec ne serait-ce qu'une dizaine, c'est dommage.

                                  Après, c'est sur que c'est une question de philo, dans hg on dit qu'il faut travailler dans la branche 'default', dans git jamais je ne travail dans 'master', toujours dans une ou plusieurs branche locale que je merge ensuite.
                                  • [^] # Re: Comparaison avec Eclipse

                                    Posté par  . Évalué à 2.

                                    Donc ce qu'on constate dans les faits c'est que avec git comme hg tu conserves les commits redondants de la vieille branche (pas de clone sélectif)


                                    La différence avec hg:
                                    - tu as l'info comme quoi y'a une branche distante mais elle est marquée (inactive).
                                    - il faut un "-f" pour le push

                                    Bref en CLI t'as l'équivalent avec un alias pour le push et un grep pour enlever les (inactive)

                                    Y'a pas de quoi fouetter un chat !

                                    Bon ok les IDE le font pas.

                                    Mais ca revient un peu à ce que je disais au dessus, y' a pas grand chose à faire dans Hg pour avoir ce comportement, non ? Tout est déjà en place et y'a juste à filtrer dans le CLI et l'API.
                • [^] # Re: Comparaison avec Eclipse

                  Posté par  . Évalué à 6.

                  > Globalement, il est rare de rentabiliser l'apprentissage de commandes,
                  marrant ça j'aurais tendance à dire le contraire, il m'est par exemple assez rare de tomber sur des machines windows sans cygwin ou cygnus d'installé.

                  J'ai déjà utilisé des front end graphique pour CVS/SVN, et même synergy.
                  Au final je revenais toujours à la ligne de commande. De temps en temps je ressortais le bouzin graphique (synergy), pour certaine tâches qui n'étaient vraiment pas simple à faire en ligne de commande (synergy est assez spécial) mais rien que le temps d'apprentissage de la commande de commit était plus rentable que2 commit via l'interface graphique.

                  J'ai appris le bash il y a des années, lui à largement été rentabilisé, idem pour le perl, et je n'ai pas trouvé d'équivalent en clickodrome

                  Pour les debugger c'est pareil, j'ai utilisé visual et différent font end à gdb ( xgdb, ddd, kdebbugger, qt-creator) et malgré tout il m'arrive de ressortir la commande gdb (gdbrc, rbreak, completion automatique, capacité d'envoyer la sortie dans un fichier text...).

                  Un autre détail qui n'est pas insignifiant avec la ligne de commande, c'est facile de faire une trace de ce que tu as fait, et c'est rapide et léger, va faire la même chose en graphique :D

                  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 0.

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

                    • [^] # Re: Comparaison avec Eclipse

                      Posté par  . Évalué à 3.

                      « Exemple con, ajouter un ; sur une colonne de texte...je sais que c'est facile a faire avec VI, c'est le genre de truc qui arrive une fois l'an...
                      Il sera plus rapide pour 99% des gens de le faire a la main que de chercher comment le faire sous VI...et dire 'oui mais la prochaine fois etcetc est fallacieux, y a souvent jamais de prochaine fois, ou alors ca sera pas la meme commande... »


                      Le KISS ça sert à ça. Pour faire une action tu utilise une combinaison de fonctions qui elles même sont suffisamment flexibles pour être utilisées dans pas mal de cas.

                      Oui l'ergonomie même dans un terminal ça a était réfléchies et chaque commandes à un sens et n'a pas était faite comme ça au hasard.

                      Donc le fait que ça ne soit pas la même commande on s'en fout. L'exemple bête c'est la sélection carrée qui permet de commenter plusieurs ligne de code en une fois ou ajouter du contenu à plusieurs lignes par exemple.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Comparaison avec Eclipse

                      Posté par  . Évalué à 2.

                      La encore mettre un breakpoint c'est un click, faire du pas a pas un click aller a point d'arret particulier un clic...et ca m'a pris ZERO comme temps d'apprentissage
                      J'apprécie cette fonctionnalité, c'est même pour ça que j'ai utilisé des front end graphique, mais il manque malgré tout
                      1) la trace/output de gdb que l'on peut stocker dans un fichier
                      2) capacité de scripter le debugger
                      4) le gdbrc
                      4) les rbreak (breakpoint sur expression rationnelles)
                      5) ignorer rapidement les 30 breakpoint suivant ou faire 100 step ou next d'un coup, oui y a ignore et autre, mais un
                      c 30, n 41 ou s 18 c'est pas la même chose que double cliquer dans la boite et autre
                      6) les tracepoint
                      quant a c, n, s, c'est assez simple c'est continue next step (on peut raccourcir les commandes, si y a pas d'ambiguïté c'est bon.

                      bah c'est facile en graphique aussi quand celui qui a fait le client graphique est pas stupide...
                      tu as des noms d'interface qui le font ? Je peux le filer brut de fonderie à un collègue qui saura rapidement reproduire ce que tu as fais, même si il est novice en la matière?

                      Il sera plus rapide pour 99% des gens de le faire a la main
                      alors là ça dépend largement de la quantité de colonne à rajouter, ensuite j'ai un préférence pour emacs
                      F3 (début d'enregistrement de macro)
                      ajouter la collonne, se placer comme au début de la macro une ligne plus bas
                      F4 (fin d'enregistrement)
                      F4 répète la dernière macro enregistré :D
                      besoin d'en faire d'autre, mixer les macros
                      pas de soucis alt-x name-last
                      lui donner un nom
                      alt-x global-set-key
                      combo de touche
                      puis le nom qu'on a donné à la macro.

                      Tu peux aussi éditer la macro précédemment enregistrée (edit-last-kbd-macro), corriger certains détails, poser des compteurs, mais là on rentre dans une utilisation un poil plus poussée (mais qui reste simple)
                      et si tu t'en sers souvent faire les global-set-key qui vont bien dans ton .emacs

                      Quant au ça n'arrivera qu'une fois j'ai plusieurs remarques
                      1) tâche réplétive -> ennui ( et parfois perte d'attention)
                      2) réfléchir comment automatiser une tâche et bien plus intéressant
                      3) Je n'ai encore jamais perdu de temps sur des "ça n'arrive qu'une fois", et il arrive fréquemment que le une fois se répète, ou sur un truc semblable.

                      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 1.

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

                        • [^] # Re: Comparaison avec Eclipse

                          Posté par  . Évalué à 2.

                          non le 4 c'est différent d'un breakpoint conditionnel (ça c'est juste un break avec un if)
                          la c'est plus la pose de plusieurs breakpoint (sur les symboles) en donnant la regexp qui va bien.

                          le gdbrc c'est un fichier que tu vas créer pour un programme spécifique qui va placer tout ce que tu veux, c'est juste que ca évite de réécrire des lignes chaque fois qu'on relance le programme. L'avantage c'est que ça se refile au collègue ou ca change de machine sans trop de soucis

                          globalement ce que je voudrais c'est une bonne interface a gdb (kgdb est pas mal, l'intégration dans qt creator est bien aussi, mais avec accès à la ligne de commande (qui gère la completion).

                          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

              • [^] # Re: Comparaison avec Eclipse

                Posté par  . Évalué à -3.

                J'imagine que tu es du genre à considérer que git est un
                subversion qui te permet de commiter en local…


                Ah si seulement c'était ça!

                Subversion est simple et les clients graphiques sont bien fait. Si seulement on pouvait versionner les modifications locales et si on n'avait pas des .svn partout, je ne donnerais pas cher de la peau de git!
                • [^] # Re: Comparaison avec Eclipse

                  Posté par  . Évalué à 3.

                  C'est juste que tu es encore coincé dans les concepts de SVN, et que tu résiste à toute nouveauté qui bouscule tes (mauvaises) habitudes.

                  DLFP >> PCInpact > Numerama >> LinuxFr.org

                  • [^] # Re: Comparaison avec Eclipse

                    Posté par  . Évalué à 2.

                    Ça change tant que ça la vie, git ?
                  • [^] # Re: Comparaison avec Eclipse

                    Posté par  . Évalué à 3.

                    Certainement, mais je ne demande qu'à évoluer. J'ai donc laissé Subversion pour GIT pour un petit projet et je suis très déçu : la doc n'est pas terrible, les messages d'erreurs sont obscurs et les clients peu ergonomiques.

                    Le socle technique est peut être très bien, mais le packaging est nul.
                    • [^] # Re: Comparaison avec Eclipse

                      Posté par  . Évalué à 1.

                      On 03/May - 12:10, alice_liddell wrote:
                      > la doc n'est pas terrible,

                      Hum je ne suis pas d'accord. D'une part, les manpages des commandes sont en
                      général très complètes, souvent avec des exemples ou de longues explications.

                      Tu disposes également d'un “guide utilisateur” qui explique clairement les
                      concepts et comment utiliser git :

                      http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

                      > les messages d'erreurs sont obscurs

                      Sur ce point là je ne peux que te rejoindre.

                      > les clients peu ergonomiques.

                      J'imagine que tu fais allusion aux clients graphiques. Pour ma part je n'en
                      utilise pas.
                    • [^] # Re: Comparaison avec Eclipse

                      Posté par  . Évalué à 2.

                      Cela peut t'interesser http://progit.org/book/

                      Perso je n'ai jamais pu blairer svn et git a ete le premier vrai systeme de VCS que j'ai utilise du coup. Devoir etre absolument connecte pour faire des commit c'est peut etre bien mais surement pas pour les gens qui voyages la moitie de leur semaine...
                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 1.

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

                        • [^] # Re: Comparaison avec Eclipse

                          Posté par  . Évalué à 1.

                          la seule manière de ne pas se faire chier et de ne pas faire chier les autres c'est de bosser seul.
                          • [^] # Commentaire supprimé

                            Posté par  . Évalué à 1.

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

                            • [^] # Re: Comparaison avec Eclipse

                              Posté par  . Évalué à 3.

                              la vitesse ? le confort ? le café ?
                            • [^] # Re: Comparaison avec Eclipse

                              Posté par  . Évalué à 2.

                              git init
                              git add tonfichier
                              git commit -m "Que c'est difficile d'utiliser Git... en effet beaucoup plus que de creer un repository local"

                              Je trouve ca plus simple mais comme on dit chacun son truc ou donne moi en trois commande comment faire l'equivalent avec svn et je reviendrai peut etre sur mon jugement de ce systeme.

                              ps: tu peux remplacer git par mercurial ou bazaar cela marche en autant de commande.
                              • [^] # Commentaire supprimé

                                Posté par  . Évalué à 0.

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

                                • [^] # Re: Comparaison avec Eclipse

                                  Posté par  . Évalué à 1.

                                  Euh je vois que tu ne t'es meme pas renseigne sur ce qu'etais Git...

                                  donc explication de texte:

                                  git init # creation du repository local
                                  git remote add nom_rep_distant le_repository_distant # ajoute le_repository_distant comme repo a distance et lui donne le nom nom_rep_distant
                                  git fetch nom_rep_distant master # recupere ce qu'il y a sur le repo master
                                  git merge # merge ton repo et le repos distant

                                  tu fais des changements sur le fichier foo.txt

                                  git add foo.txt #tu rajoutes ce fichier dans ceux que tu veux commiter sur ton repo local
                                  git commit -m "changement sur foo.txt" #tu commit

                                  lorsque tu as ta connection a internet

                                  git push nom_rep_distant # tu push vers repo distant

                                  Maintenant j'ai aussi donne un lien plus haut ou tu peux trouver plus de renseignement mais avant de critiquer (et d'etre agressif) cela serait pas mal que tu te renseignes un chouilla. Et si ce qui est decris au dessus est faisable avec SVN pas de probleme donne moi les commandes.
                                  • [^] # Commentaire supprimé

                                    Posté par  . Évalué à 1.

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

                                    • [^] # Re: Comparaison avec Eclipse

                                      Posté par  . Évalué à 1.

                                      relis toi a tete repose et tu verras que le ton de ton message precedent (et de celui la d'ailleurs) est "legerement" agressif.

                                      Si SVN te convient tant mieux. Moi je ne l'aime pas et Git (ou Mercurial) me convienne mieux. C'est MON choix que j'ai fait en testant pour voir l'outil qui me convient le mieux.

                                      Enfin pour repondre un peu tes affirmations je ne ferais que citer la documentation officielle de SVN:

                                      http://svnbook.red-bean.com/nightly/fr/svn.basic.repository.(...)

                                      Subversion est un système centralisé

                                      Tu n'aimes pas l'idee des DVCS c'est pas un probleme il y a encore des outils tel que SVN et CVS mais laisse les personnes voulant se servir d'autres outils tranquille.

                                      J'ai teste SVN et cela ne me convient pas, il te convient tant mieux. Point final.
            • [^] # Commentaire supprimé

              Posté par  . Évalué à 1.

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

        • [^] # Re: Comparaison avec Eclipse

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

          L'aspect plugin dans Kde, ça n'est pas nouveau, les KPart doivent dater de plusieurs versions majeures (sinon de l'origine).

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Re: Comparaison avec Eclipse

            Posté par  . Évalué à 1.

            Je pense que ça a été introduit dans KDE 2.0
            (la première version de konqueror, qui est un gros conteneur de kpart, est arrivée avec KDE 2.0)
        • [^] # Re: Comparaison avec Eclipse

          Posté par  . Évalué à 2.

          Le plugin git gère le bistruct ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Un pas vers KDE ?

    Posté par  . Évalué à 3.

    J'aime beaucoup travailler en C/C++ (et tout pleins d'autres langages - j'aime bien m'amuser) et je ne supporte pas eclipse/netbeans (netbeans ne veut même pas se lancer sur mon netbook).

    Pour le moment j'utilise avec bonheur vim et je tente régulièrement emacs et geany. Il y a un seul bémol, tout ce qui est refactoring et complétion intélligente (proposer une fonction en rapport au type de retour de la fonction, proposer des fonctions ou des variables qui existe dans le contexte courant,...), ben j'ai pas.

    Donc ça m'intéresserais pas mal de voir KDevelop 4.0, seul problème... KDE. Moi je suis sous awesome et je pense pas le quitter pour une histoire d'IDE.

    Donc est ce que KDevelop est utilisable sans avoir trop de dépendance avec KDE ou alors il va falloir que je me tourne vers QDevelop ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Un pas vers KDE ?

      Posté par  . Évalué à 3.

      Ça dépend de ce que tu appelles "trop de dépendance", chez moi (Arch) il dépend de kadebase qui est énorme (et revient presque à installer KDE moins les applications et plasma). C'est sûr que ça fait beaucoup.
      • [^] # Re: Un pas vers KDE ?

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

        en même temps quand on a un disque dur de plus de 4GB (tous les pc depuis 2000) et plus de 256MB de ram (j'ose espérer qu'un développeur en a plus), ça n'a strictement aucun impact...
        • [^] # Re: Un pas vers KDE ?

          Posté par  . Évalué à -7.

          Et ta connexion Internet, elle fait 4 Go/s ou 256 Mo/s en descendant ?
          • [^] # Re: Un pas vers KDE ?

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

            Tu veux re-télécharger tout KDE-base et KDevelop tous les jours ?

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: Un pas vers KDE ?

      Posté par  . Évalué à 2.

      Il y a un seul bémol, tout ce qui est refactoring et complétion intélligente (proposer une fonction en rapport au type de retour de la fonction, proposer des fonctions ou des variables qui existe dans le contexte courant,...), ben j'ai pas.

      Tu veux parler de l'omnicompletion ? http://vim.wikia.com/wiki/Omni_completion

      Et pour le refactoring en Python tu as Bicycle Repair Man ça doit exister pour d'autres langages
      • [^] # Re: Un pas vers KDE ?

        Posté par  . Évalué à 3.

        Non, par exemple :
          1 template<typename T> class foo : public T {
          2 };
          3 
          4 class bar {
          5 public:
          6   void baz() {}
          7 };
          8 
          9 int main(int argc, char **argv) {
         10   foo t;
         11   t. [???]
         12 }
        À la ligne 11, vim ne devrait me proposer que baz, alors qu'il me propose tout un bordel sans grand rapport avec la choucroute (y compris « template », hum). D'ailleurs, question pour les gens l'ayant sous la main : est-ce que Kdevelop 4 traite ce cas ?
        • [^] # Re: Un pas vers KDE ?

          Posté par  . Évalué à 1.

          Et tu as installé OmniCppComplete ?
          • [^] # Re: Un pas vers KDE ?

            Posté par  . Évalué à 3.

            Maintenant oui, et ça n'améliore pas vraiment les choses.

            Je ne jette pas la pierre aux développeurs de ces outils, analyser syntaxiquement du C++ de façon exhaustive et correcte est un problème cauchemardesque ; peut-être que le développement de clang va permettre d'avoir un outil libre et adapté utilisable dans les IDE et éditeurs face à GCC-XML qui semble pas parfaitement adapté et peu maintenu.
            • [^] # Re: Un pas vers KDE ?

              Posté par  . Évalué à 6.

              KDevelop complètera sans soucis ton cas. Son moteur est vraiment très performant (il y a un an, il faisait une analyse bien plus fine que celle d'eclipse).
              Il fait vraiment de la complétion sémantique et de plus, souligne les erreurs relevées par son frontend de manière incrémentale (donc avant compilation)... Un beau produit, testé sur du C++ plutôt complexe (mais il n'invente pas de complétion "potentielle" pour les "templates" non instantiés).
              C'est le premier outil qui me paraît faire une analyse satisfaisante sur du C++ tordu, très agréable pour prendre en main des projets très "méta".

              À côté de ça, je le fais tourner sous enlightenment avec une installation minimale de KDE, c'est tout à fait acceptable et l'intégration de QT à GTK est transparente au niveau "Look'n'feel".
              • [^] # Re: Un pas vers KDE ?

                Posté par  . Évalué à 1.

                Et tu sais si il est facilement utilisable par d'autres programmes ? (les fonctionnalités d'eclipse sont facilement utilisables sous vim en utilisant eclim)
        • [^] # Re: Un pas vers KDE ?

          Posté par  . Évalué à 2.

          J'irais même plus loin avec ça :

          class Foo{
          public:
          bool isTrue(int c);
          void imachin();
          };

          int main(void){
          Foo f;
          int v1;
          float v2;
          if(f.i<ici proposer isTrue et pas imach>
          }


          Et ensuite proposer v1 et pas v2 pour le paramètre.

          Je vais voir l'omni-complétion.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Un pas vers KDE ?

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

            Alors j'ai essayé les deux exemple avec Kdevelop, et oui, l'auto completion est intelligente.

            Pour le cas du template, pas de problème. Kdevelop instancie les template et complète correctement.

            Kdevelop détecte les types des argument, et mettra v1 en premier (dans les "best-matches").

            Par contre, il ne fait pas de détection du type lorsque on fait un if.
            • [^] # Re: Un pas vers KDE ?

              Posté par  . Évalué à 6.

              Par contre, il ne fait pas de détection du type lorsque on fait un if.

              Ça me semble tout à fait normal vu qu'il y a autant de chance qu'on appel une fonction booléenne qu'on comparre la sortie d'une autre fonction avec !<=>. Le seul truc qui serait à filtrer, ce sont les void.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Un pas vers KDE ?

                Posté par  . Évalué à 2.

                Le seul truc qui serait à filtrer, ce sont les void.
                Ben en l'occurrence, c'est le cas de la méthode imachin()...
      • [^] # Re: Un pas vers KDE ?

        Posté par  . Évalué à 2.

        Je suis entrain de l'essayer et chez moi ctags refuse l'option --c++kinds=+p...

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Un pas vers KDE ?

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

      Idem, jamais pu sortir d'un éditeur minimal. Dans le genre, jed (http://www.jedsoft.org/jed/) est parfait. C'est sûr qu'il manque la complétion et le refactoring, et évidemment je lis ces commentaires et lorgne sur kdevelop, mais à chaque fois j'en reviens à jed :)
      • [^] # Re: Un pas vers KDE ?

        Posté par  . Évalué à 5.

        pareil pour moi, depuis des années je tourne sur le minuscule éditeur de texte. Récemment j'ai fait du Qt et j'ai fait un peu de Qt-creator, mais au final tant que je ne fais pas de Qt, je me contente de mon petit emacs.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # vim et refactoring (Was: Un pas vers KDE ?)

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

      Pour le refactoring sous vim, il y a une solution assez complète pour Python évoquée plus haut, et ceci [http://code.google.com/p/lh-vim/wiki/lhRefactor] pour lequel j'espère faire une release bientôt (il faut que je me motive à terminer les docs). Un bémol pour l'extraction de fonctions, je n'ai pas encore intégré ctags pour déterminer les variables entrantes/sortantes relativement au bloc de code extrait.
  • # Comment qu'on importe des projets cmake/qmake ?

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

    Ça doit être moi mais je n'arrive pas à importer mes projets qmake ou cmake :s Quelqu'un à compris comment ce truc marche ?

    Sinon, ArchLinux a le paquet kdevelop 4.0-1 de dispo depuis hier, c'est cool :)
  • # Interface de l'enfer

    Posté par  . Évalué à 7.

    http://logram-project.org/files/~steckdenis/MainWindow.png

    - Pourquoi le menu File est au milieu ?
    - Pourquoi y'a un menu DTD ?
    - Pourquoi y'a des onglets au même niveau que les menus ?
    - Pourquoi on a l'impression que tous les widgets flottent un peu partout n'importe comment ?
    - Pourquoi faut tourner la tête dans 3 sens différents pour pouvoir tout lire ?
    - Pourquoi les flèches de l'arbo sont aussi petites ? (ça doit être pratique à cliquer)
    - Pourquoi y'a 2 champs textes côte à côte en haut ? pour se tromper plus facilement ?
    - Pourquoi y'a des boutons flèches dans tous les sens ?
    - Pourquoi y'a des boutons en haut, sur les côtés, et en dessous de chaque panel ?
    - Pourquoi le tooltip est blanc sur fond blanc ?
    - Pourquoi l'indicateur de ligne/col est en haut à côté des onglets ?
    - Pourquoi y'a un panel 'Projects' et un autre 'Project Selection' ?
    - Pourquoi y'a tellement de couleurs dans la coloration syntaxique qu'on met 2 heures à comprendre quelle couleur correspond à quoi ?

    C'est juste moi, ou cette interface c'est l'enfer ?
    • [^] # Re: Interface de l'enfer

      Posté par  . Évalué à 4.

      Non ça n'a pas l'aire d'être l'enfert mais j'ai trouvé certaines de tes remarques pertinentes (la 6, la 7, la 8, la 9 et la 10).

      Le DTD j'imagine qu'ils ont voulu permettre à l'utilisateur de gérer son temps avec une technique à eux.
      Pour le nombre de couleur de la coloration moi je préfère. Il me faut de toute manière pas mal de temps pour apprendre le set de couleur et ça permet de mieux se repérer dans son code (de manière très visuelle quand on fait un scroll).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Interface de l'enfer

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

      - Pourquoi le menu File est au milieu ?

      Car le menu est divisé en 3 partie:
      * une partie pour les options touchant les projects/sessions
      * une autre partie pour les options du doculent/fichier
      * et la dernière partie une pour les autre options.

      - Pourquoi y'a un menu DTD ?

      Je n'ai pas cette option. Cela doit certainement venir d'un plugin. Mais ce n'est pas par défaut.
      D'ailleurs, je n'ai pas non plus les menus View, Tags et Toolbars


      - Pourquoi y'a des onglets au même niveau que les menus ?

      Pour gagner de la place.
      Sur le sreenshot ça paraît confus car il y a plus d'entrée dans les menu et donc il y a des flèches.
      Mais chez moi c'est correct.

      - Pourquoi faut tourner la tête dans 3 sens différents pour pouvoir tout lire ?

      Pour gagner de la place mais je n'ai pas besoin de tourner la tête pour lire. Et comme ces élément ne change pas, pas vraiment de problème.

      - Pourquoi y'a 2 champs textes côte à côte en haut ? pour se tromper plus facilement ?

      Car l'un est le quick open qui te permet de faire une recherche dans ton projet, et l'autre te montre la fonction dans laquelle tu navigue.
      Je ne me suis jamais trompé en les utilisant.

      - Pourquoi y'a tellement de couleurs dans la coloration syntaxique qu'on met 2 heures à comprendre quelle couleur correspond à quoi ?

      Ce n'est plus de la coloration syntaxique, mais de la coloration sémentique.
      Ça peut parraître un peu déroutant au début, mais une fois qu'on s'y habitue, on ne veux plus s'en passé. voir http://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from-(...)

      - [Plein d'autre question sur des détails cosmétique]

      KDevelop, (comme beaucoup d'autre projet libre) est fait par des développeurs qui n'ont pas forcément le souci du détail pour les détails cosmétique.

      Dans ma boite, il y a quelqu'un dont le boulot est uniquement de travailler sur les détails cosmétiques de l'application (qui est en fait un IDE aussi). Il s'assure que tous les trucs sont aligné au pixel près etc.

      Dans un précédent projet de logiciel libre auquel j'ai participé, un utilisateur contribuais en perfectionnant les .ui de toutes les boites de dialogues du projet. C'était très utile et il a malheureusement arrêté.

      Si tu fais attention au détails et que tu as envie de contribuer, tu peux toujours aider. Les changement cosmétique ne demande d'habitude pas d'être un pro en programation.
    • [^] # Re: Interface de l'enfer

      Posté par  . Évalué à 5.

      - Pourquoi le menu File est au milieu ?

      Ça me semble plus logique de mettre les menus de gestion du projet avant la gestion du fichier. En tout cas, ça ne me semble pas dramatique.

      - Pourquoi y'a un menu DTD ?

      Il y a pas ça chez moi, à mon avis c'est un plugin qu'il a installé.

      - Pourquoi y'a des onglets au même niveau que les menus ?

      Parce que ça change entièrement l'inteface, c'est une sorte menu, c'est plus compréhensible que des radios buttons

      - Pourquoi on a l'impression que tous les widgets flottent un peu partout n'importe comment ?

      Parce que tu as de l'eau sur ton écran.

      - Pourquoi faut tourner la tête dans 3 sens différents pour pouvoir tout lire ?

      Pour faire de la place au code

      - Pourquoi le tooltip est blanc sur fond blanc ?

      Ça doit être le thème qui est différent, chez moi il est jaune pâle.


      C'est juste moi, ou cette interface c'est l'enfer ?

      C'est juste moi ou ça été l'enfer pour toi lorsque le design de l'icône de firefox a été changé avec la 3.6?

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Interface de l'enfer

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

      Bonjour,

      1) Pourquoi le menu File est au milieu ?

      Il est bien à gauche du menu dans lequel il se trouve. Les menus de KDevelop sont architecturés un peu spécialement du fait de la modularité du machin. J'admets que ce n'est pas beau, mais c'est pratique d'avoir toujours les mêmes menus aux mêmes endroits (ceux qui ont utilisé Konqueror en faisant autre-chose que juste du web comprendront).

      2) Pourquoi y'a un menu DTD ?

      Je ne sais pas, il est vide.

      3) Pourquoi y'a des onglets au même niveau que les menus ?

      Parce qu'ils changent l'espace de travail (barre d'outils, documents ouvertes) mais pas les menus, et que la place doit être faite pour le code, pas l'interface. Donc on les met là où il y a de la place.

      4) Pourquoi on a l'impression que tous les widgets flottent un peu partout n'importe comment ?

      Parce que tu es habitué aux interfaces simplistes et pauvres en GTK qui obligent d'ouvrir 3 fenêtres différentes avec 6 niveaux de menus pour avoir la même chose (non je ne vise pas GIMP).

      5) Pourquoi faut tourner la tête dans 3 sens différents pour pouvoir tout lire ?

      Parce qu'on n'a pas besoin de toute lire en même temps, généralement. On code tranquillement, avec la doc à côté, et on peut ouvrir d'autres fichiers :) .

      6) Pourquoi les flèches de l'arbo sont aussi petites ? (ça doit être pratique à cliquer)

      Parce que KDE est configurable et que j'aime les petites flèches, tout simplement. On peut aussi mettre des + , choisir la taille des flèches, etc.

      7) Pourquoi y'a 2 champs textes côte à côte en haut ? pour se tromper plus facilement ?

      Y'en a un avec «Quick Open...» dedans qui permet de rapidement ouvrir un fichier en fonction de ce qu'on tape dedans. L'autre permet de naviguer de fonction en fonction dans le fichier courant.

      8) Pourquoi y'a des boutons flèches dans tous les sens ?

      Y'a que deux boutons flèches, c'est raisonnable. Les autres flèches viennent du fait que j'ai rétréci la fenêtre au maximum (on ne voit pas toute la largeur du menu, il manque un bout d'onglet, les barres d'outils ne rentrent pas).

      En 1280x1024, ça rentre impeccablement et il n'y a plus de flèches.

      9) Pourquoi y'a des boutons en haut, sur les côtés, et en dessous de chaque panel ?

      Chaque bouton permet d'ouvrir/fermer un panel. Par exemple, si je clique sur le bouton Projects à gauche, ça me ferme le panel Projects et je gagne de la place.

      Les panels peuvent être changés de côtés, et même transformés en panels flottants (hors de la fenêtre).

      10) Pourquoi le tooltip est blanc sur fond blanc ?

      Si ça avait été une autre couleur, t'aurais demandé «Pourquoi les tooltips sont en rose sur fond blanc avec du texte noir dedans ? Pour bien nous pêter les yeux ?».

      Le contour est suffisamment gros pour qu'on le voie. Le but de KDevelop est d'être utilisable.

      11) Pourquoi l'indicateur de ligne/col est en haut à côté des onglets ?

      Parce qu'une barre des tâches occuperait 20px de haut sur toute la largeur de la fenêtre et qu'il faut mettre ça là où il y a de la place, toujours dans un soucis d'optimisation de l'espace.

      De plus, comme on change souvent de document, l'oeil a l'habitude de se balader dans cette zone, donc c'est justement mieux placé à l'utilisation que si c'était en bas.

      12) Pourquoi y'a un panel 'Projects' et un autre 'Project Selection' ?

      J'avoue que je ne sais pas trop. On peut ouvrir plusieurs projets, et il me semble qu'on peut alors choisir dans Project Selection quels projets afficher dans l'arbre au-dessus.

      13) Pourquoi y'a tellement de couleurs dans la coloration syntaxique qu'on met 2 heures à comprendre quelle couleur correspond à quoi ?

      Chaque variable a sa couleur, et ça met un peu de gaité dans le code :) .

      Ce qui n'est pas variable a des couleurs facilement reconnaissable. Gras pour les mots-clefs, bleu clair pour les types génériques (void, int, bool, double, etc), bleu marine pour une fonction membre (en gras si elle est à nous).

      Donc non, c'est au contraire une très belle interface conçue avec la plus grande attention (KDevelop était stable depuis 1 an, j'ai suivi sur le SVN cette dernière année, et plus de 50% des commits visaient à rendre l'interface utilisable).

      KDevelop, on l'essaie pendant 10 minutes qu'on ne veut plus le quitter. Tout est sous la main, là où on veut, et c'est relativement rapide.
      • [^] # Re: Interface de l'enfer

        Posté par  . Évalué à 1.

        "Le but de KDevelop est d'être utilisable."
        Il existe des logiciels dont le but est de ne pas être utilisable ?

        L'interface est déroutante au début mais on s'y habitue très vite.
        • [^] # Re: Interface de l'enfer

          Posté par  . Évalué à 5.

          Il existe des logiciels dont le but est de ne pas être utilisable ?

          git, emacs ?
        • [^] # Re: Interface de l'enfer

          Posté par  . Évalué à 3.

          des logiciels, je ne sais pas, a part peut être vi, mais pour les sites internet
          voyage-sncf, cdiscount, allocine (surtout avec son flash d'intro), une bonne partie des journaux en ligne (ceux qui ne gèrent pas le redimensionnement des polices )

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Interface de l'enfer

        Posté par  . Évalué à 1.

        5) Pourquoi faut tourner la tête dans 3 sens différents pour pouvoir tout lire ?

        Parce qu'on n'a pas besoin de toute lire en même temps, généralement. On code tranquillement, avec la doc à côté, et on peut ouvrir d'autres fichiers :) .


        Ah oui, ça, c'est une erreur d'avoir des lignes d'écritures qui se lisent dans deux sens opposés. ( les menus: " Filesystem project classes " à gauche et " sniplet documentation " à droite ) .

        Sur les plans normalisés, il n'y a que 2 sens de lecture. Pas 3.

        Sedullus dux et princeps Lemovicum occiditur

        • [^] # Re: Interface de l'enfer

          Posté par  . Évalué à 2.

          Ben ce reste kde
          c'est vrai que l'ihm n'est pas terrible par défaut, mais l'interface tu en fais ce que tu en veux
          si tu veux tout mettre à gauche, tu mets tout à gauche, en bas, en flottant ou je ne sais quoi d'autre, tu disposes à ta convenance.
    • [^] # Re: Interface de l'enfer

      Posté par  . Évalué à 3.

      C'est juste moi, ou cette interface c'est l'enfer ?

      Ben non, c'est un outil KDE.

Suivre le flux des commentaires

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