Discussion :

[dourouc05]

Mise à jour 2013
Ce sondage a été renouvelé en 2013. Venez participer, cela se passe ici :

Quel est votre EDI préféré pour Qt en 2013 ?
--------------------------------------------------------------------------

L'année dernière était lancé le dernier sondage sur les EDI utilisés avec Qt.

Depuis lors, l'environnement Qt n'a pas tellement évolué sur le plan technique (le support de Qt Quick était déjà entré dans Qt Creator, il n'a fait que se perfectionner), bien que la communauté a dû évoluer (le projet d'open governance est arrivé à terme avec la création du Qt Project, Nokia qui continue de se désinvestir de Qt, notamment).

Avez-vous changé d'EDI préféré sur cette période ? Restez-vous sur le même, au vu de ses récentes évolutions ? Envisagez-vous de changer, au vu de ce qui est prévu pour Qt 5 et C++ 11 ? Quelle en serait, selon vous, la killer feature ?

[VivienD]

J'utilise Qt Creator vu que cet environnement effectue déjà tout ce dont j'ai besoin. Enfin, presque: je n'ai pas encore trouvé la fonction qui permettrait, lors de la compilation, de copier automatiquement les fichiers .dll dans le dossier de l'application ou, même, dans un dossier spécifique qui, lui, serait dans le même dossier que l'application.

[acesyde]

De même que VivienD,

QtCreator est un bon IDE comparé à ses débuts avec le monde merveilleux du multi fenêtres

L'avantage de Qt Creator est d'être multiplateformes, l'installer sous ubuntu / windows et autres c'est très rapide.

Maintenant cela fait quelques temps que je ne l'ai pas utilisé, mais il manquerait peut être un système de plugins pour rajouter des fonctionnalités à l'IDE.

[dourouc05]

il manquerait peut être un système de plugins pour rajouter des fonctionnalités à l'IDE.

Ça tombe bien, ça y est déjà : http://qt-project.org/wiki/Qt_Creator_Plug-in_Gallery.

[acesyde]

Ça tombe bien, ça y est déjà : http://qt-project.org/wiki/Qt_Creator_Plug-in_Gallery.

Faut vraiment que je sorte de ma caverne

[stef-13013]

Franchement quand on voit aujourd'hui les "tank" VS2010, Xcode,... (et je parle pas des prochaines versions !) et toutes les ressources de malades qu'il faut comparées à QtCreator, il n'y a pas photo.

Creator est encore un peu jeune sur certains aspects mais il progesse à grand pas. En plus multi-plateforme !!

Hors-sujet ou presque:
Maintenant que Nokia ont laché l'affaire, Qt va devenir de plus en plus fort et (j'espère) incontournable !! Il FAUT qu'il soit présent sur Android, iOS and co...

[gbdivers]

J'utilise Qt Creator vu que cet environnement effectue déjà tout ce dont j'ai besoin. Enfin, presque: je n'ai pas encore trouvé la fonction qui permettrait, lors de la compilation, de copier automatiquement les fichiers .dll dans le dossier de l'application ou, même, dans un dossier spécifique qui, lui, serait dans le même dossier que l'application.

C'est un problème de qmake, pas de QtCreator
méthode 1 : utiliser la variable DLLDESTDIR aille directement au bon endroit
méthode 2 : utiliser la variable QMAKE_POST_LINK de qmake pour écrire une ligne de commande pour faire la copie (OS dépendant)
méthode 3 : QtCreator permet l'utilisation d'outils externe, en particulier les outils de packaging pour des installations automatiques (par exemple CPack)

Maintenant cela fait quelques temps que je ne l'ai pas utilisé, mais il manquerait peut être un système de plugins pour rajouter des fonctionnalités à l'IDE.

Petite précision : la doc qui explique comment développer des plugins pour Qt Creator est là : http://doc.qt.nokia.com/qtcreator-extending/index.html (voir en particulier tout en bas de la page : Qt Creator API Reference)
Certaines choses sont très simples (ajouter une coloration par exemple), d'autres demande de connaître un peu l'API, mais pour avoir testé, rien de compliqué

Franchement quand on voit aujourd'hui les "tank" VS2010, Xcode,... (et je parle pas des prochaines versions !) et toutes les ressources de malades qu'il faut comparées à QtCreator, il n'y a pas photo.

Pour avoir vu la présentation des TechDays de 2010 sur les fonctionnalités de Visual Studio, il faut pas en effet comparer à QtCreator (je dis ça sans méchanceté pour QtCreator, je suis un utilisateur convaincu, mais il y a quand même un gouffre entre les 2). Et ça date de 2010, j'imagine même pas la dernière version

Maintenant que Nokia ont laché l'affaire, Qt va devenir de plus en plus fort et (j'espère) incontournable !! Il FAUT qu'il soit présent sur Android, iOS and co...

Nokia n'a jamais interdit les portages sur les autres plateformes. Au contraire : c'est bien sous la "période" Nokia (par des devs payés par Nokia) qu'a été développé le Platform Abstraction Layer pour rendre Qt moins dépendant de la plate-forme et permettre ainsi les portages vers Android et iOs.
Sinon, Qt est un projet open source, donc si on veut des portages... just do it

[VivienD]

C'est un problème de qmake, pas de QtCreator
méthode 1 : utiliser la variable DLLDESTDIR aille directement au bon endroit
méthode 2 : utiliser la variable QMAKE_POST_LINK de qmake pour écrire une ligne de commande pour faire la copie (OS dépendant)
méthode 3 : QtCreator permet l'utilisation d'outils externe, en particulier les outils de packaging pour des installations automatiques (par exemple CPack)
[...]

En utilisant ta première méthode, si j'écris dans mon fichier .pro DLLDESTDIR = ./libs/, mon application saura donc que les fichiers .dll dont il a besoin se trouvent dans le dossier libs/ qui se trouve juste à côté d'elle. Est-ce que cette ligne permet aussi la copie des fameuses bibliothèques?

[gbdivers]

non
Cela indique l'emplacement des dll créés

Pour indiquer à ton application va chercher ses dll :
* windows : pas le choix, ça doit être dans c:/windows, c:/windows/systems et dans le même répertoire (en gros, de mémoire. Il est peut être possible d'ajouter des chemins supplémentaires avec PATH)
* linux : idem que windows + les RPATH
* dans les 2 cas, il est possible également de créer des plugins et les charger avec QLibrary (et dans ce cas, tu mets les dll où tu veux ; c'est ce que fait Qt avec les plugins pour les formats d'image par exemple)

[air-dex]

Toujours Qt Creator pour moi. Pour la suite, j'attends qu'il se perfectionne sur le QML (l'aide surtout) et une meilleure intégration de Qt Linguist.

[Freem]

Pour indiquer à ton application va chercher ses dll :
* windows : pas le choix, ça doit être dans c:/windows, c:/windows/systems et dans le même répertoire (en gros, de mémoire. Il est peut être possible d'ajouter des chemins supplémentaires avec PATH)
* linux : idem que windows + les RPATH

Sur ce coup, windows et linux fonctionnent presque de la même façon:
Windows n'a que la variable PATH, Linux à PATH et LDLIBRARY (ou un truc dans le même genre).
L'OS va chercher les libs dans les chemins indiqués par ceux-ci.


Sinon, par rapport au sujet... Je n'utilise que peu, voire jamais Qt, mais la dernière fois que j'ai tenté de participer à un projet Qt, je me suis avéré incapable d'utiliser C::B pour compiler, parce que je ne pige pas trop comment marche qmake, sûrement.
Résultat, je me suis retrouvé obligé d'utiliser QtCreator (sous linux, VS ne marche pas ), que je n'aime absolument pas, ce qui a été la cause de la cessation de ma tentative de contribution.

Les raisons à l'époque étaient l'UI très "plastique" mais surtout très fixe, difficile à modifier et qui bouffait trop de place (à cette époque, ça remonte à 2009, l'écran de mon PC de bureau était un 14"... et de façon générale, je n'aime pas avoir une UI envahissante. D'ailleurs, mon 1er réflexe avec C::B c'est de virer toutes les barres d'outils au 1er lancement. Systématiquement.)

Je n'ai pas réessayé depuis, donc peut-être que ces points se sont améliorés. D'un autre côté, C::B commence aussi à me lasser sur certains points:
_ assistant de création de classe très moyen (bien que supérieur à celui de VS 2008, mais ça m'empêche pas de le trouver mal fichu et de commencer à en écrire un moi-même)
_ assistant de création de nouveau projet bof (je dirais que c'est proche de celui de VS 2008 si je dois comparer) qui, en plus, ralentit le démarrage (trop de modèles/scripts à charger, C::B à trop de choix xD)

Donc si QtCreator s'est amélioré sur les points que je lui reprochai lors de mon essai (principalement l'UI) pourquoi ne pas lui redonner une chance...

[gbdivers]

J'avais oublié LDLIBRARY. Par contre, il y a quand même les rpath sous linux en plus

Pour l'UI de QtCreator, globalement, est reste identique, il y a surtout eu des ajout de fonctionnalités... donc ça risque de ne pas te plaire (un petit screen en pièce jointe)

[Freem]

J'avais oublié LDLIBRARY. Par contre, il y a quand même les rpath sous linux en plus

Pour l'UI de QtCreator, globalement, est reste identique, il y a surtout eu des ajout de fonctionnalités... donc ça risque de ne pas te plaire (un petit screen en pièce jointe)

Je ne connaît pas les rpath, je vais me renseigner sur ce que c'est... en espérant tomber sur autre chose que la distribution du même nom (qui à l'air intéressante, cela dis)

Sinon, effectivement, l'interface me semble toujours aussi répulsive. Et surtout, inutilisable sur une machine ayant un petit écran.
Pour mieux expliquer, voici 2 screens de mon installation de C::B (pour celui du bas, j'ai simplement utilisé F1 pour le project manager - parce que j'ai un problème avec le raccourcis d'origine, SHIFT+F2. En fait, toutes les Fxx ont un souci quand elles sont combinées, mais ce n'est pas du à C::B - et F2 pour les logs).
La différence est frappante, et je pense que tout le monde comprendra pourquoi utiliser C::B sur un netbook n'est pas trop pénible, alors que QtCreator me semble... ingérable.
Après, les interfaces, ce n'est qu'une simple question de goût.

[Linunix]

Tout comme VivienD
j'utilise Qt creator car il répond à mes besoins.

[air-dex]

Puisque personne ne la encore faite je me lance : pourquoi ne pas avoir donné à des IDE comme KDevelop et QDevelop une catégorie qui ne soit pas "Autres" ?

[El Capitan]

Moi, je suis parfaitement content avec Qt Creator. Peut-être que je me lancerai dans d'autres si j'ai le temps, mais pour le moment, ça va très bien comme-ça, merci

[gbdivers]

Puisque personne ne la encore faite je me lance : pourquoi ne pas avoir donné à des IDE comme KDevelop et QDevelop une catégorie qui ne soit pas "Autres" ?

Parce que sur les 44 personnes qui ont répondu jusque maintenant, 1 à répondu autre. Reste à savoir si cette personne utilise KDevelop ou QDevelop

[Squisqui]

En tant qu'amateur, il y a des petites choses que je ne pige pas vraiment à droite à gauche, qmake, les shadow builds... (oui, je sais, la doc' est là pour ça).
Mais je trouve QtCreator vraiment sympa pour... Qt (je crois que c'est le but... ).
Tout se fait tout seul, il n'y a plus qu'à taper le code.
Pour tout le reste, je reste habitué à C::B... Quand c'est pas vim.

[air-dex]

En tant qu'amateur, il y a des petites choses que je ne pige pas vraiment à droite à gauche, qmake, les shadow builds... (oui, je sais, la doc' est là pour ça).

Le code que tu écris en utilisant Qt n'est pas du "vrai C++" (qui n'a pas de mot-clé "emit" à ma connaissance par exemple). qmake transforme ce "code Qt" en "code vrai C++" pour être compilé avec l'utilitaire make bien connu des développeurs. Il vaut mieux le connaitre si tu développes en Qt.

"shadow build" est juste un gros mot (de Qt Creator ?) pour dire "je ne compile pas dans le répertoire des sources mais dans un répertoire de même niveau dans l'arborescence".

[VivienD]

non
Cela indique l'emplacement des dll créés

Pour indiquer à ton application va chercher ses dll :
* windows : pas le choix, ça doit être dans c:/windows, c:/windows/systems et dans le même répertoire (en gros, de mémoire. Il est peut être possible d'ajouter des chemins supplémentaires avec PATH)
* linux : idem que windows + les RPATH
* dans les 2 cas, il est possible également de créer des plugins et les charger avec QLibrary (et dans ce cas, tu mets les dll où tu veux ; c'est ce que fait Qt avec les plugins pour les formats d'image par exemple)

Euh... je suis quelque peu... «perplexe»...

Tu aurais un petit exemple pour la route une application pour Windows et Linux?

EDIT: Pour l'exemple, admettons que l'application se trouve dans le dossier C:\chemin\vers\mon\application ou respectivement /chemin/vers/mon/application, et que les bibliothèques se trouvent dans le dossier C:\chemin\vers\mon\application\libs ou respectivement /chemin/vers/mon/application/libs.