Je passe ces vacances à apprendre à écrire des applications Qt. Je lisais à propos de Qt Designer il y a quelques heures à peine, ce qui m'a fait me demander: qu'est-ce que les gens qui écrivent des applications du monde réel dans Qt utilisent pour concevoir leurs interfaces graphiques? En fait, comment les gens conçoivent-ils les interfaces graphiques en général?
Pour ma part, j'ai trouvé que l'écriture du code à la main était conceptuellement plus simple que d'utiliser Qt Designer, bien que pour des interfaces graphiques complexes, Designer puisse avoir un sens. Il est possible d'utiliser de grandes interfaces graphiques avec Designer, mais avec le temps, leur gestion risque de devenir très difficile à mesure que la complexité augmente (ce n'est que mon avis). J'ai également téléchargé le code source AmaroK pour jeter un coup d'œil à ce que ces gars faisaient, et j'ai trouvé de nombreux appels à addWidget () et à leurs amis, mais aucun de ces fichiers XML créés par Designer (à part: AmaroK doit être mon application préférée de tous les temps). toute plate-forme).
Quelle est alors la "bonne" façon de créer une interface graphique? Designer ou code? Voyons, pour cette discussion, les types d’IUG suivants:
Notre expérience avec Designer a commencé en Qt3.
Qt3
À ce stade, Designer était principalement utile pour générer du code que vous compileriez ensuite dans votre application. Nous avons commencé à utiliser à cette fin, mais avec tout le code généré, une fois que vous l'avez édité, vous ne pouvez plus revenir en arrière et le régénérer sans perdre vos modifications. Nous avons fini par prendre le code généré et tout faire à la main désormais.
Qt4
Qt4 a considérablement amélioré Designer. Il ne génère plus seulement du code, mais vous pouvez charger dynamiquement vos fichiers Designer (en xml) et les connecter dynamiquement aux objets en cours d'exécution de votre programme } _ - pas de code généré, cependant, vous devez nommer les éléments dans Designer et coller avec les noms pour ne pas casser votre code.
Mon évaluation est qu’elle est loin d’être aussi utile que Interface Builder sur Mac OS X, mais à ce stade, je pouvais voir l’utilisation des fichiers Designer directement dans un programme.
Nous ne sommes pas revenus dans Designer depuis Qt3, mais nous l’avons toujours utilisé pour prototyper et déboguer des dispositions.
Pour vos problèmes:
Vous pouvez probablement utiliser les dialogues standard proposés par Qt . QInputDialog ou si vous sous-classe QDialog, veillez à utiliser QButtonDialogBox la plate-forme appropriée.
Vous pourriez probablement faire quelque chose de plus limité, comme xPad avec des fonctionnalités limitées de Designer.
Je ne pensais pas que vous pourriez écrire quelque chose comme OpenOffice uniquement avec Designer, mais ce n’est peut-être pas le problème.
J'utiliserais Designer comme un autre outil, tout comme votre éditeur de texte. Une fois que vous avez trouvé les limites, essayez un outil différent pour ce nouveau problème. Je suis tout à fait d’accord avec Steve S pour dire que l’un des avantages de Designer est qu’une autre personne qui n’est pas un programmeur peut faire la mise en page.
D'après mon expérience avec Qt Designer et d'autres toolkits/UI-tools:
La complexité peut souvent être traitée dans un outil d'interface utilisateur en divisant la conception en plusieurs fichiers d'interface utilisateur. Incluez de petits groupes logiques de composants dans chaque fichier et traitez chaque groupe comme un seul widget utilisé pour créer l'interface utilisateur complète. Le concept de widgets promus de Qt Designer peut aider à cet égard.
Je n'ai pas trouvé que l'ampleur du projet fait une différence. Votre expérience peut varier.
Les fichiers créés avec des outils d'interface utilisateur (vous pouvez éventuellement les écrire à la main si vous le souhaitez) peuvent souvent être chargés dynamiquement au moment de l'exécution (Qt et GTK + fournissent tous deux cette fonctionnalité). Cela signifie que vous pouvez apporter des modifications à la mise en page et les tester sans recompiler.
En définitive, je pense que le code brut et les outils d’interface utilisateur peuvent être efficaces. Cela dépend probablement beaucoup de l'environnement, de la boîte à outils/de l'interface utilisateur et, bien sûr, des préférences personnelles. J'aime les outils d'interface utilisateur, car ils me permettent d'être rapidement opérationnel et de permettre des modifications simples plus tard.
L’organisation pour laquelle je travaille a porté son application graphique sur Qt il y a plusieurs années. Je pense qu'il y a plusieurs aspects qui méritent d'être mentionnés:
Ma propre expérience, qui remonte à environ. 4 ans, en utilisant Qt3.3, c’est qu’un comportement dynamique dans les dialogues n’était pas possible dans Designer.
Juste pour dire que j'ai écrit et entretenu des interfaces graphiques complexes dans Qt sans utiliser Qt Designer - non pas parce que je n'aime pas Qt Designer, mais parce que je n'ai jamais eu le temps de travailler de cette façon.
C'est en partie une question de style et d'où vous venez: quand j'ai commencé à utiliser Qt, j'avais eu une expérience horrible de Dreamweaver et de Frontpage et d'autres outils HTML visuels, et j'avais de loin préféré écrire du code avec HomeSite et recourir à Photoshop pour une mise en page complexe. problèmes.
Il existe un danger avec les IDE de code visuel que vous essayez de conserver au sein des outils visuels, mais que vous finissiez par devoir modifier le code - de manière mal comprise.
Lors de l’apprentissage du développement d’un iPhone, par exemple, j’ai trouvé frustrant de toucher un objet visuel «magique» («glisser du cercle vide de l’inspecteur de connexions vers l’objet de la fenêtre d’Interface Builder ...») qui serait plus simple (par exemple, moi) pour comprendre en clair vieux code.
Bonne chance avec Qt - c'est une excellente boîte à outils, quelle que soit l'utilisation que vous en faites, et Qt Creator semble être un excellent IDE.
J'ajouterais que l'une des raisons de l'utilisation du concepteur graphique était le manque de gestionnaires de disposition dans Win32, par exemple. Seul un positionnement absolu était possible, et le faire à la main aurait tout simplement été nul.
Depuis que je suis passé de Delphi à Java pour les applications avec interface graphique (en 2002), je n’ai plus utilisé de concepteurs. J'aime beaucoup plus les gestionnaires de mise en page. Et oui, vous obtenez le code standard, mais le déplacement d'objets sur un concepteur d'interface utilisateur peut prendre autant de temps que le changement de standard. De plus, je serais coincé avec un IDE lent; c'est pour le cas Java/C #, OK, alors que pour Qt (en particulier Qt4), cela ne s'applique pas. Pour Qt3, je me demande pourquoi on devrait éditer le code généré - n'était-il pas possible d'ajouter du code dans d'autres fichiers? Pour quelle raison?
À propos des cas discutés: 1) L’écriture d’une interface graphique codée à la main est plus rapide, du moins si vous connaissez vos bibliothèques. Si vous êtes un débutant et que vous ne le connaissez pas, vous gagnerez peut-être du temps et en apprendrez moins avec un concepteur, car vous n'avez pas besoin de connaître les API que vous utilisez. Mais "apprendre moins" est le facteur clé, alors dans les deux cas, je dirais que l'interface graphique à la main.
2) Les barres de menus sont assez gênantes pour écrire du code. Pensez également aux détails tels que les accélérateurs, etc. Pourtant, cela dépend de ce que vous avez l'habitude de faire. Après un certain temps, il peut être plus rapide de taper ce type de machine plutôt que de pointer-cliquer dans le concepteur pour corriger toutes ces propriétés, mais juste si vous pouvez réellement taper comme dans une machine à écrire (comme ces administrateurs pour lesquels la saisie de commandes Unix est plus rapide en utilisant une interface graphique).
3) J'étendrais la réponse pour le cas n ° 2 à celui-ci. Notez que, pour les plates-formes Win32, il est possible que le recours à des concepteurs générant des ressources Win32 soit plus rapide à charger (aucune idée de cela).
Cependant, j'aimerais mentionner ici un problème potentiel lié à l'utilisation de Qt Designer. Cas réel: il a fallu quelques secondes (disons 10) pour charger une boîte de dialogue Java complexe (la boîte de dialogue Préférences pour l'éditeur de texte d'un programmeur) avec beaucoup d'options. Le correctif correct aurait été de ne charger chacun des onglets que lorsque le programmeur voulait les voir (je me suis rendu compte après) en ajoutant une méthode distincte à chaque jeu de préférences pour construire son interface graphique.
Si vous concevez tous les onglets et le sélecteur d'onglets avec un concepteur, pouvez-vous le faire aussi facilement? J'imagine qu'il pourrait y avoir un exemple similaire dans lequel une interface graphique codée à la main vous donne plus de flexibilité et dans une application aussi grosse, vous en aurez probablement besoin, même à des fins d'optimisation.
L'un des principaux avantages de l'utilisation de designer pour la création d'interfaces graphiques réside dans le fait que d'autres programmeurs peuvent modifier ou gérer facilement les formulaires et les widgets sans avoir à se plonger dans un code complexe.
C'est étrange que vous disiez que le code d'écriture est plus simple que de manipuler des objets dans un environnement graphique. C'est une évidence.
Le concepteur est là pour vous faciliter la vie et, à long terme, rend votre code plus facile à gérer. Il est plus facile de consulter le concepteur pour voir à quoi ressemble votre interface utilisateur, puis de lire le code et d'essayer d'imaginer à quoi elle pourrait ressembler.
Avec Qt actuel, vous pouvez faire presque tout depuis le concepteur et les très peu de choses que vous ne pouvez pas faire, vous pouvez corriger avec très peu de lignes de code dans le constructeur . Prenez par exemple l'exemple le plus simple - ajouter une connexion signal-slot. En utilisant le concepteur, c'est aussi simple qu'un double clic. Sans le concepteur, vous devez rechercher la signature correcte du signal, éditer le fichier .h, puis éditer écrire votre code dans le fichier .cpp. Le concepteur vous permet d’être au-dessus de ces détails et de vous concentrer sur ce qui compte vraiment: la fonctionnalité de votre application.
J'aime d'abord me tourner vers le concepteur pour développer des widgets d'interface graphique. Comme mentionné dans les autres messages, c'est plus rapide. Vous obtenez également un retour immédiat pour voir si cela "semble bon" et si cela ne dérange pas l'utilisateur. Le concepteur est une raison majeure pour laquelle j'ai choisi Qt par rapport à d'autres kits d'outils. J'utilise principalement le concepteur pour créer les boîtes de dialogue uniques.
Cela dit, je fais la fenêtre principale et tous les widgets complexes à la main ... Je pense que c'est ce que Trolltech avait prévu. QFormLayout est une classe qu'ils fournissent pour créer facilement par programme un dialogue de saisie.
En passant, le concepteur de Qt 4 n’est pas un IDE semblable à celui qu’il avait dans Qt 3. C’est juste un éditeur pour éditer des fichiers .ui. Je l'aime comme ça. La nouvelle plate-forme croisée IDE va s'appeler Qt Creator.
C'est un vieux post, mais je vous conseillerais de regarder Clementine - un lecteur de musique dérivé (je pense) d'Amarok. Ils utilisent Qt4 et d'après ce que je peux voir, il existe un dossier ui dans le dossier src du projet. Comme on peut s'y attendre, dans le dossier ui , ils ont toutes sortes de fichiers .ui. Si vous compilez et démarrez Clementine, vous verrez que l'interface graphique est assez complexe et assez agréable.
Pour moi, cela dépend de combien de logic est encapsulé dans le widget/GUI. S'il ne s'agit que de simples formulaires, je préfère utiliser QtDesigner.
S'il contient des contrôles complexes ou une interaction, j'ai tendance à le programmer.
Nous utilisons Qt Designer si quelqu'un a besoin de créer une interface graphique.
Le but est de ne créer que de petits widgets pour certaines tâches (comme vous le feriez dans une conception de classe), puis de les regrouper dans un "gui".
Ainsi, vos widgets sont hautement réutilisables et peuvent être utilisés pour Guis de manière modulaire. Vous devez juste spécifier quels signaux chaque Widget envoie et quels créneaux ils fournissent.
Nous créons également des fichiers .ui qui pourraient être générés pendant le processus de construction. Jusqu'à présent, il n'était pas nécessaire d'éditer ces fichiers à la main.
Construire différentes parties de votre interface utilisateur
dans différents fichiers .ui utilisant QtDesigner,
puis les réunir (et ajouter des complications) dans le code.
Il y a des choses que vous ne pouvez pas faire dans Qt Designer, vous ne pouvez le faire qu'en code,
so Qt Designer n’est qu’une (excellente) partie de la chaîne outils .