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
- KDevelop (80 clics)
- Code source (27 clics)
- Annonce sur le KDE Dot (5 clics)
# J'aime
Posté par William Briand . Évalué à 3.
# Mais surtout...
Posté par DLFP est mort . Évalué à 8.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Mais surtout...
Posté par William Briand . Évalué à 3.
[^] # Re: Mais surtout...
Posté par fridim . Évalué à 5.
# Comparaison avec Eclipse
Posté par Aris Adamantiadis (site web personnel) . Évalué à 5.
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 riri le breton (site web personnel) . Évalué à 4.
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 Aris Adamantiadis (site web personnel) . Évalué à 6.
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 Aris Adamantiadis (site web personnel) . Évalué à 3.
svn co svn://anonsvn.kde.org/home/kde/trunk/playground/devtools/kdevelop4-extra-plugins/
[^] # Re: Comparaison avec Eclipse
Posté par eMerzh (site web personnel) . Évalué à 4.
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 Etienne Juliot (site web personnel) . Évalué à 3.
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 barmic . Évalué à 8.
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 Etienne Juliot (site web personnel) . Évalué à 0.
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 barmic . Évalué à 3.
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 Joël SCHAAL . Évalué à 4.
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 lolop (site web personnel) . Évalué à 2.
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]
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Comparaison avec Eclipse
Posté par DLFP est mort . Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par tesiruna . Évalué à 2.
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 pasBill pasGates . Évalué à 6.
[^] # Re: Comparaison avec Eclipse
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par tesiruna . Évalué à 4.
> 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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par tesiruna . Évalué à 1.
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 Thomas Douillard . Évalué à 8.
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 Antoine . Évalué à 4.
À 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 CrEv (site web personnel) . Évalué à 2.
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 El Titi . Évalué à 3.
http://mercurial.selenic.com/wiki/NamedBranches
[^] # Re: Comparaison avec Eclipse
Posté par CrEv (site web personnel) . Évalué à 2.
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 El Titi . Évalué à 2.
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 CrEv (site web personnel) . Évalué à 2.
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 El Titi . Évalué à 2.
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 François (site web personnel) . Évalué à 2.
[^] # Re: Comparaison avec Eclipse
Posté par CrEv (site web personnel) . Évalué à 2.
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 El Titi . Évalué à 2.
http://lazymalloc.blogspot.com/2009/03/uses-of-mercurials-bo(...)
[^] # Re: Comparaison avec Eclipse
Posté par CrEv (site web personnel) . Évalué à 2.
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 El Titi . Évalué à 2.
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 fearan . Évalué à 6.
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 Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par barmic . Évalué à 3.
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 fearan . Évalué à 2.
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par fearan . Évalué à 2.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par alice . Évalué à -3.
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 DLFP est mort . Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Comparaison avec Eclipse
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Comparaison avec Eclipse
Posté par Gof (site web personnel) . Évalué à 4.
C'est juste qu'il faut un temps d'adaptation. Mais une fois qu'on a compris le fonctionnement de git, on ne veux plus toucher à SVN.
[^] # Re: Comparaison avec Eclipse
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
Une vraie gestion des branches ça change la vie de ceux qui veulent coder sur plusieurs choses en même temps.
[^] # Re: Comparaison avec Eclipse
Posté par alice . Évalué à 3.
Le socle technique est peut être très bien, mais le packaging est nul.
[^] # Re: Comparaison avec Eclipse
Posté par tesiruna . Évalué à 1.
> 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 Albert_ . Évalué à 2.
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par tyoup . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par tyoup . Évalué à 3.
[^] # Re: Comparaison avec Eclipse
Posté par Albert_ . Évalué à 2.
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 Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par Albert_ . Évalué à 1.
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par Albert_ . Évalué à 1.
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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison avec Eclipse
Posté par lolop (site web personnel) . Évalué à 4.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Comparaison avec Eclipse
Posté par wismerhill . Évalué à 1.
(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 barmic . Évalué à 2.
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 barmic . Évalué à 3.
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 monde_de_merde . Évalué à 3.
[^] # Re: Un pas vers KDE ?
Posté par Aris Adamantiadis (site web personnel) . Évalué à 3.
[^] # Re: Un pas vers KDE ?
Posté par auve . Évalué à -7.
[^] # Re: Un pas vers KDE ?
Posté par lolop (site web personnel) . Évalué à 6.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Un pas vers KDE ?
Posté par HardShooter . Évalué à 2.
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 auve . Évalué à 3.
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 HardShooter . Évalué à 1.
[^] # Re: Un pas vers KDE ?
Posté par auve . Évalué à 3.
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 Defre . Évalué à 6.
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 HardShooter . Évalué à 1.
[^] # Re: Un pas vers KDE ?
Posté par barmic . Évalué à 2.
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 Gof (site web personnel) . Évalué à 2.
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 claudex . Évalué à 6.
Ç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 aedrin . Évalué à 2.
Ben en l'occurrence, c'est le cas de la méthode imachin()...
[^] # Re: Un pas vers KDE ?
Posté par barmic . Évalué à 2.
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 HardShooter . Évalué à 3.
et pour le C++ il y a aussi une page ici : http://vim.wikia.com/wiki/VimTip1608
[^] # Re: Un pas vers KDE ?
Posté par pilouche (site web personnel) . Évalué à 1.
[^] # Re: Un pas vers KDE ?
Posté par fearan . Évalué à 5.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Un pas vers KDE ?
Posté par vincent_k (site web personnel) . Évalué à 10.
[^] # vim et refactoring (Was: Un pas vers KDE ?)
Posté par lmg HS (site web personnel) . Évalué à 2.
# Comment qu'on importe des projets cmake/qmake ?
Posté par Martin Peres (site web personnel) . Évalué à 5.
Sinon, ArchLinux a le paquet kdevelop 4.0-1 de dispo depuis hier, c'est cool :)
[^] # Re: Comment qu'on importe des projets cmake/qmake ?
Posté par steckdenis (site web personnel) . Évalué à 2.
C'est normalement en passant par Projects»Open/Import.... Là, tu clique sur ton fichier CMakeLists.txt principal (ou le fichier .pro si le plugin QMake est installé), et ça roule.
[^] # Re: Comment qu'on importe des projets cmake/qmake ?
Posté par Martin Peres (site web personnel) . Évalué à 1.
J'avais essayé et le filtre ne m'autorisais que l'ouverture de projet kdev4. Cela dit, j'ai rebooté entre temps, c'est peut-être la raison du pourquoi ça marche maintenant.
Merci en tout cas
# Interface de l'enfer
Posté par sebn . Évalué à 7.
- 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 barmic . Évalué à 4.
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 Gof (site web personnel) . Évalué à 6.
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 claudex . Évalué à 5.
Ç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 steckdenis (site web personnel) . Évalué à 6.
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 Thrillseeker . Évalué à 1.
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 Antoine . Évalué à 5.
git, emacs ?
[^] # Re: Interface de l'enfer
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Interface de l'enfer
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: Interface de l'enfer
Posté par fearan . Évalué à 3.
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 houra . Évalué à 1.
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 Alex . Évalué à 2.
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 Antoine . Évalué à 3.
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.